Unhandled rejection warnings when expecting a rejection

I'm not using Bluebird but similarly to this thread I'm getting the same warning errors of unhanded rejection when actually expecting a rejection.
Here's a repo to reproduce: https://github.com/laggingreflex/chai-as-promised-reject-test
It was mentioned chai-as-promised is indeed handling the errors (here) but I think they're not being handled soon enough. Putting a console.log there shows that it reaches that code only after the warning has been displayed:
(node:5580) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: rejected
  promise
(node:5580) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)
>>> assertIfNegated about to be called... <<<
    √ should be rejected

  1 passing (48ms)

This is a bug introduced in Node.js v7.0.0. I can only recommend not using v7 for now. See https://github.com/nodejs/node/pull/8217.

I am also experiencing this issue on Node 6.9.1 and:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
This spec should fail:
import chai from 'chai';
import chaiAsPromised from 'chai-as-promised';

chai.use(chaiAsPromised);
const expect = chai.expect;

describe('Test', () => {
  it('should fail', () => {
    expect(Promise.resolve(2)).to.eventually.equal(1);
  });
});

Instead, the output is:
  Test
    ✓ should fail
(node:52529) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): AssertionError: expected 2 to equal 1

  4 passing (27ms)

And the process exits with a 0 exit code.

Ugh, it does seem this kind of major change slipped in to Node.js 6.x as well, although that bug thread is confusing :(.

@darkobits I think you need to return the expect
  it('should fail', () => {
    return expect(Promise.resolve(2)).to.eventually.equal(1);
  });

Also I think my (OP) problem was that I was using chai v4, I tested it again and the original test lib works well with chai 3.5

@laggingreflex do you think this might be a regression in chai v4? If so please please do file a report on the chai issue tracker 😄

Also might wanna check out #157. However, I submitted that a long time ago and there have been a lot of changes since then; it may need further updating.

Is this still considered a node bug?  I am seeing this too in node 8.0.0.
const chai = require('chai');
chai.use(require("chai-as-promised"));
const assert = chai.assert;

describe('rejection assertion', function(){
  it('should correctly fail the test', function(){
    const p = Promise.resolve("resolved")
    return assert.isRejected(p)
  })
})

The above erroneously passes:

rejection assertion
✓ should correctly fail the test
(node:27794) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): AssertionError: expected promise to be rejected but it was fulfilled with 'resolved'
(node:27794) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
1 passing (37ms)

    "chai": "^4.0.1",
    "chai-as-promised": "^6.0.0",
    "mocha": "^3.4.2"

@adamvoss chai-as-promised doesn't support Chai v4 yet. See #198 and #157.

I'm having a similar issue right there
source code:
export default class SomeManager {
  /**
   * @param {SomeOtherManager} someOtherManager
   */
  constructor(someOtherManager) {
    this._someOtherManager = someOtherManager;
  }

  /**
   * @return {Promise}
   */
  execute() {
    return this._someOtherManager.get('id');
  }
}

And my test
import chai from 'chai';
import cp from 'chai-as-promised';
import SomeManager from './../../lib/manager/someManager';
import SomeOtherManager from './../../lib/manager/someOtherManager';
import {beforeEach, describe, it} from 'mocha';
import sinon from 'sinon';

describe('SomeManager', () => {
  chai.use(cp);
  let expect = chai.expect;
  let someManager;
  let someOtherManagerMock;

  beforeEach(() => {
    someOtherManagerMock = sinon.createStubInstance(SomeOtherManager);
    someManager = new SomeManager(someOtherManagerMock);
  });

  describe('execute', () => {
    it('should reject promise', () => {
      // Arrange.
      someOtherManagerMock.get.withArgs('id').returns(Promise.reject());

      // Act.
      let actual = someManager.execute();

      // Assert.
      return expect(actual).to.eventually.be.resolved;
    });
  });
});

OUTPUT:
SomeManager
    execute
      ✓ should reject promise
(node:11844) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): undefined

@zazoomauro In your case, the problem is that .resolved isn't an assertion in chai-as-promised. I think you need .fulfilled.

@meeber Thanks!

I also have the same problem
node: v6.11.0
chai: 3.5.0 -- also tested on ^4.0.1
chai-as-promised: ^7.1.1
mocha: ^3.4.2

Have the same issue.

Same here:
node: v6.9.1
chai: 3.5.0
chai-as-promised: 7.1.1
mocha: 3.5.3
@vitalets, I think this is not a solution but rather a hack to hide the warning. But it can work in case someone wants to avoid pull request issues :)

There are multiple issues brought up by people in this thread. Some of the issues were resolved with the release of chai@4 and chai-as-promised@7. Some of the issues were resolved by properly returning the promise in the test so mocha can properly handle the asynchronous test. However, the original problem demonstrated by the OP here isn't resolved, and I don't think it can be resolved by chai or chai-as-promised.
Consider the OP's original example with a console.log added inside the it block:
const chai = require( 'chai' );
const promised = require( 'chai-as-promised' );

chai.use( promised );
chai.should();

const somePromise = new Promise( () => {
  throw new Error( 'rejected' );
} );

describe( 'promise', () => {
  it( 'should be rejected', () => {
    console.log("NOOOOOOOOOOOOO WHYYYYYYYYYYYYYYYY");
    return somePromise.should.be.rejected;
  } );
} );

Output:

mocha index.js

(node:2769) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: rejected
(node:2769) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
promise
NOOOOOOOOOOOOO WHYYYYYYYYYYYYYYYY
(node:2769) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)
✓ should be rejected
1 passing (13ms)

An UnhandledPromiseRejectionWarning is generated before the it function is even executed. Moving the Promise declaration into the describe function or inside of a before function results in the same behavior. Only by moving the Promise declaration directly into the it function (or a beforeEach function) does the warning go away.
I don't have time to dig deeper, but this suggests to me that Mocha is introducing at least a one tick delay before it functions are executed.

return the expect for me worked, and makes sense.

Pseudo-cross-posting idea from https://github.com/mochajs/mocha/issues/3009#issuecomment-347190839
I have something of a workaround for https://github.com/domenic/chai-as-promised/issues/173#issuecomment-330409841
const chai = require( 'chai' );
const promised = require( 'chai-as-promised' );

chai.use( promised );
chai.should();

const makeSomePromise = () => new Promise( () => {
  throw new Error( 'rejected' );
} );

describe( 'promise', () => {
  it( 'should be rejected', () => {
    return makeSomePromise().should.eventually.be.rejected; // note the addition of `.eventually`
  } );
} );

One thing to be aware of, although I think this is inherent to promises' eagerness and error handling design and will be relevant no matter whether Mocha is changed to have no tick delays*, is that if you recreate the promise on a per-test basis then every test must handle its rejection (even if it isn't relevant, e.g. if you're testing that it starts off pending), while on the other hand if you were to reuse a rejected promise in multiple tests then the first test must handle the rejection and once it does so there will be no warning if any subsequent test fails to do so even if it needs to (in other words, even if Mocha allowed you to assign a promise once and use it in multiple tests, it'd be almost equivalent to assigning the promise and immediately calling somePromise.catch(()=>{}) to suppress rejection warnings for that promise). In that sense, creating a new promise for every test (whether with beforeEach or with a thunk as in my workaround) would be the more safe/robust approach (if, in certain unusual cases, slightly annoying).
*(NOTE: In this example any asynchronous test or hook can introduce a delay between the variable assignment outside of any test or hook and actually getting to run this test; you would have to move that variable assignment into a before/beforeEach hook that runs just prior to this test in addition to Mocha removing the delays.)

Return expect won't sovle the problem, the test can not pass still, and I think this is a upstream problem, cuz it happens on assert package built in Node, mayby mocha.
describe('Whay', function () {
  describe('It should pass but can not pass', function (done) {
    whay('test', function (_, obj) {
      console.log(obj)
      // assert.equal(obj.keyword, 'test')
      // done()
    })
  })
})

Here it complains obj is undefined, but it is logged to console successfully.

Seeing this with Node 6.10.2 and Mocha 3.5.3. Has anybody found a reasonable fix/workaround?
My tests cases are of the following form:
it('should throw for unexpected HTTP errors', () => {
     return expect(methodThatTriggersRejection())
          .to.be.rejectedWith(expectedError);
});

@hiranya911 It looks to me like something else might be going on in your example than what is being discussed here. For example, I just tested this standalone example that's based on your example, and it works:
function methodThatTriggersRejection () {
  return Promise.reject(TypeError('testing'));
}

it('should throw for unexpected HTTP errors', () => {
     return expect(methodThatTriggersRejection())
          .to.be.rejectedWith(TypeError, 'testing');
});

Are you sure that methodThatTriggersRejection is returning a rejected Promise object?

It has a promise chain whose catch block throws an exception. I assumed this gets translated into a rejected promise, especially since the assertions in my tests pass:
return Promise.resolve()
  .then(() => {

  })
  .catch((error) => {
     throw new MyException("error message"); // This is what my assertions are checking for
  });

@hiranya911 Does the example I provided work without warnings if you copy/paste it into your current project? If not, does it still display warnings if you copy/paste it into an empty project? I suspect you'll need to produce a standalone, reproducible example for us to be able to assist further.
Something is causing an extra tick of the event loop to occur between your promise being rejected and it being "handled" by chai-as-promised. However, based on the examples you've provided so far, it doesn't look to be the same issue as discussed in this thread. The issue being discussed in this thread is that when a promise is rejected outside of the it block from which the promise is being asserted upon, an extra tick of the event loop occurs due to Mocha internals. In your example, the promise is being rejected within the same it block and thus wouldn't be subjected to the Mocha-induced extra tick.

@meeber I think I've narrowed it down a bit. I'm using sinon to stub out certain operations, and simply having the following (by itself with no other code) in the test triggers warnings:
let stub = sinon.stub(HttpRequestHandler.prototype, 'sendRequest')
        .returns(Promise.reject(expectedResult));

@meeber I think I'm running into the issue described here... http://clarkdave.net/2016/09/node-v6-6-and-asynchronously-handled-promise-rejections/
Solution would be to use sinon-as-promised package.

@hiranya911 Thanks! that worked for me. Another alternative is to use callsFake() instead of returns() to return the rejected promise from the stub.

i encountered same issue but was able to resolve this by using async/await like below.
await expect(medProfile.allergiesSection.getTagName()).to.eventually.equal('div');
originally i had it like below. which threw rejection when element not found. but cucumber test passed without catching that error.
Then(/^user should see allergies and health conditions section$/, async () => {   await expect(medProfile.allergiesSection.getTagName()).to.eventually.equal('div');   await expect(medProfile.healthConditionsSection.getTagName()).to.eventually.equal('div'); });

all of these pass without a unhandled promise rejection warning and without any await or returning anything.
I think the major issue here is the bad documentation of chai-as-promised that confuses everybody.
expect(Promise.reject).to.be.rejected
expect(Promise.reject).to.be.rejectedWith(YourError)
expect(Promise.reject).to.be.rejectedWith(Error).eventually.with.property('name', 'YourError')

but this shows warnings even with eventually
expect(Promise.reject).to.eventually.throw(Error)

Still having this issue, behaving randomly, this always works
      it('handles message error', (done) => {
        const error = new Error('Solver internal error');
        producerRPC.sendPayload(consumerHost, {} as any).catch((err) => {
          expect(err).to.be.equal(error);
        });
      });

While this does not
    describe('sendPayload.robust', () => {
      it('handles message error', async () => {
        const error = new Error('Solver internal error');
        return producerRPC.sendPayload(consumerHost, {} as any).should.eventually.be.rejectedWith(error);
      });
    });


move examples from gists into repo (#51)

This is an initial stab at #51. The examples are all bundled into repl.js, which I don't think is too much of a problem. There was a little funkiness I had to work around - when you initialize the REPL you have to do so via data and when you load a different example later you have to do so via json. But switching examples, loading data= links from the guide, and loading examples from gists should theoretically be all working.

wzrd.in is down, which is also breaking the examples using d3 on the existing REPL. I don't know, historically, how often this happens - or what would be involved in switching to another service for this.

thanks — have fixed the Travis config so it shouldn't accidentally deploy commits to non-master branches any more, whoops! Longer term I'm thinking the site should be a proper Node/Svelte app rather than a purely static site, which would make it a lot easier to keep all these things in separate files and serve them up as JSON on demand, but this is a good solution in the meantime

wzrd.in is down

I don't know if there any other ready-made services — it's possible to host your own but I don't know if we want to get into that. We should probably just display an error message in the UI rather than crashing completely


[TODO] Try using v8 as JS engine?

duktape is powerful and fast, but I would like to try something even biger: v8
It's very complex to build for an unknown system (Switch), but I will try.

Why did you close this?

Tried, too complex, would require a lot of work


Add pyproject.toml to shellplot

Add a pyproject.toml to shellplot.
At this point only want the minimum. So add the [project] tag only for now.
Consult PEP 621 as to how to correctly add metadata for shellplot.
https://peps.python.org/pep-0621/

The PEP 621 is a historical document.
For the latest info need to refer to Python Packaging User Guide
https://packaging.python.org/en/latest/specifications/pyproject-toml/#pyproject-toml-spec

Also had to refer to list of classifiers on pypi.org/classifers


Investigate and strengthen Zarf Registry's ability to avoid being evicted

Is your feature request related to a problem? Please describe.
In certain situations the Zarf Registry may be evicted due to resource pressure. I believe I have experienced it happening when the node it was on had disk pressure, but I can't be sure that that was the exact cause due to other factors that were happening. It's also possible for the pod to be evicted due to memory pressure if it is using more memory than its request, which is currently set to only 256Mi.
If Zarf Registry is evicted, it is possible that won't be able to come back up, if the node it is scheduled to does not still have the image saved on its disk, due to either garbage collection or a dead node.
Describe the solution you'd like
Zarf Registry is configured such that its likelihood that it will be evicted due to resource pressure (either disk or memory) is minimized
Describe alternatives you've considered
None at the moment, though once the feature to have an externally sourced registry is available that will likely be a good option for making Zarf Registry much more robust.

This is a duplicate/related to #752 will add a note to it to check this.


URL activation event for extensions

Can we have a way to activate the extension on vscode:// URLs? Just as it is possible to open a file/project, it would be useful to have this for extensions.
One use-case that is critical for my extension (Slack Chat) is to enable OAuth, with a redirect URL. Other apps on Mac use URL scheme handlers to setup OAuth redirection, and it would be great if vscode could do so too.

Is this what you are looking for? https://github.com/Microsoft/vscode/blob/049cb9dde0839c0602a8ebeec8e7c7fcebcee4b6/src/vs/vscode.proposed.d.ts#L505

This looks exactly like what I need, thank you. I will remember to check the proposed APIs before creating an issue the next time. Is there any timeline on when this will be in stable?

This API is coming out for stable only in July.


SSL issue

I'm quite lost regarding where exactly this issue occurs, so please excuse me if it turns out that it has nothing to do with this package.
When I test my webhook in the Paddle dashboard, I get error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure. First, I thought that Paddle was connecting over SSLv3 but that seems highly unlikely as I've done some searching and it seems this is ancient and not recommended encryption.
On my nginx server I have (this might be relevant to the issue):
ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparams.pem;

The reason that I'm posting this issue here is that WebhookController has
$verified = openssl_verify(
  serialize($data),
  base64_decode($encodedSignature),
  openssl_get_publickey(config('paddle.public_key')),
  OPENSSL_ALGO_SHA1
);

Judging from the response that I get in the Paddle dashboard I still think it's on their end but I wanted to double check if the issue could come from the code above, or that maybe you ran into this issue as well while working on this package.
I have set my public_key in my ENV file and run config:cache on deployment.

Check #11 - that should solve it.

That solved it, thanks for the quick reply!


travis updates

THIS PR SHOULD NOT BE MERGED
I’m update some of the travis configurations. I need the tests to run for master branch PRs, which is why I’m opening this PR. BUT, it is not a proper release and therefore should not be merged into master (as per our versioning and release guide

Only deploy the doxygen when the master branch is updated. Currently, the doxygen is updated for PRs. Moving this section to deploy should mean that it is not run for PRs. But we may have to change the repo settings to also notify travis on master branch pushes.
Build CODES for integration testing. The intent is to only do this on master branch PRs (aka releases).

Finally got Travis to work properly, but found a bug with the CODES test suite (see CODES-org/CODES#206).


What happens if you change the prompt after a Dream has been created and you press the + button?

What happened?

Create Dream
Don't select Y or N
Change prompts
Press +

Does the new Dream created take the new prompt into account? Or do I have to press N and create a new Dream for the new prompt to take affect?
Steps to reproduce the problem

Create Dream
Don't select Y or N
Change prompts
Press +

Does the new Dream created take the new prompt into account? Or do I have to press N and create a new Dream for the new prompt to take affect?
What should have happened?
See above
Commit where the problem happens
bf21c19
What platforms do you use to access openOutpaint?
MacOS
What browsers do you use to access the UI ?
Mozilla Firefox
Browser Extensions/Addons
None
AUTOMATIC1111 webUI Commandline Arguments
See above
Additional information
No response

well huh; i don't so much think it's a bug in that it's always been kind of a "more, please" button and i suppose i assumed "more, please" implied "more of the same thing, please", but i can absolutely see the value in tweaking the prompt... added in https://github.com/zero01101/openOutpaint/commit/674bdbe11b710668e29a8c776d900de243427afc, check the config window to enable the option since it's kind of a "breaking" change to existing functionality

I wouldn't mind a new button that's "gen more with current prompt" or such.


[backport/1.24] build: Bump image -> 7304f974de2 (#25089)

and revert:

#24979

Signed-off-by: Ryan Northey<EMAIL_ADDRESS>
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/retest

/retest

@mattklein123 i think this is good to land
apologies for force i wanted to replace the commit


Multi Billing Plan Support

Solves #76, #96, #94

Ability for multi-plan billing and usage charhes built-in
Plans are now stored in database (new plans table)
New freemium flag on shops table allowing a shop to use the app for "free"
New plan_id added to shops and charges tables so a charge and shop can be tied to a plan
Config entries modified for config/shopify-app.php to support new billing features
Charge creation on BillingController moved to firstOrNew instead of a new instance directly, solving #94
Default view added for declined charges or issues with charges, solving #96
Addition of usageCharge route on BillingController to automatically handle creation of usgae charges on a recurring charge, given values passed by get/post
BillingPlan modified to work with multiple plans
Added ability to define a default plan on install

Coverage decreased (-0.4%) to 99.642% when pulling 0fc583b44281e0bdb2ce5330a1ade9d7e928f65e on 76-multi-plans into 2572975bf3b38d4393d7200fbd1dc16053bf7efb on master.


Backpressure support

RxJava supports backpressure.  I don't believe that Hystrix currently participates in backpressure, as it is creating an Observable from scratch by wrapping logic around either a scheduled HystrixCommand.run() or a HystrixObservableCommand.construct().
I need to write some code examples to see what happens when backpressure over network boundaries happens, and Hystrix is involved in the data flow.
Also note that features like semaphore/thread-pool rejection are analogous to Observable.onBackpressureDrop.
This is marked as 'discussion' as I am not sure what the relationship between Hystrix and backpressure is yet.  If anyone on the community has ideas, or better yet code, I'd love your input.

Well one of the problem is that Hystrix isn't really a streaming/pub/sub/reactive library but more of a command/request/reply/blocking command pattern. That is Hystrix Observables are generally just [Single](http://reactivex.io/documentation/single.html) (in theory you could do streaming). Generally backpressure is not needed when you want a single item.
The problem when you start doing streaming is resource management. Request/Reply doesn't have this problem because once the reply is filled you are done and resources can be cleaned up (there is only one endpoint you have to worry about not responding). Thus if you want to start investigating I think that resource management is starting point. I would imagine this would require a significant addition to Hystrix to manage this (albeit I would be highly interested in this feature and in theory you could use the same principles ie semphores and timeouts).
TLDR You are now worrying about two endpoints instead of one (ie in reactive-stream parlance the subscriber needs to call request along with the publisher actually fulfilling that request).
A library to investigate that sort of deals with the whole reactive-streams management rather well is reactor ( I believe rxjava2 even borrowed some code from them).

I generally agree with your points for HystrixCommand.  Have you seen HystrixObservableCommand?  This is intended to wrap calls like async HTTP calls, that may return streams (like RxNetty).  In a case where we do I/O that supports backpressure, I'd like Hystrix to not get in the way of expressing that backpressure.
I'll check out reactor - thanks for the link!

Ha sorry the snapshot site is pending update (goes down when update takes place for a couple minutes).   Meanwhile there is still https://github.com/reactor/reactor.
Nevertheless I would be interested in providing any assistance if you guys want to return something like HystrixFluxCommand (Flux being our Rx lite Publisher implementation for N data) and HystrixMonoCommand (Mono being our Rx lite Publisher implementation for 1 data).

As far as my understanding goes the HystrixObservableCommand has Hystrix only participate in the subscription thread (ie subscribeOn) which is good and bad. Its good for fake streams that are blocking but bad for reactive push streams.
Its bad because in the reactive-streams model the subscribe phase should be nonblocking. That is if your blocking on subscribe your doing it wrong (see my recent question here https://github.com/reactive-streams/reactive-streams-jvm/issues/276 ).
So using a thread ExecutionIsolationStrategy for a true reactive command is a complete waste. Its also fairly risky because you might want to have thousands of open streams (ie some chat Netty like server). What is useful are probably semaphores at a fairly high count in this case.
So yeah Hystrix does get in the way if you naive and use the the thread policy.

I tested Hystrix with a couple unit tests with backpressure and it appears it doesn't support it at all.
There is some RxJava operator that overrides the Producer.request to always use Long.MAX_VALUE on the returned Observable.
        TestHystrixObservableCommand<Integer> command = getCommand(isolationStrategy, executionResult, 50, AbstractTestHystrixCommand.FallbackResult.UNIMPLEMENTED, 1000000);
        long observedCommandDuration = 0;

            final CountDownLatch latch = new CountDownLatch(1);
            command.toObservable().subscribe(new Subscriber<Integer>() {
                @Override
                public void onStart() {
                    request(1);
                }
                @Override
                public void onCompleted() {
                    latch.countDown();
                }

                @Override
                public void onError(Throwable e) {
                    throw new UnsupportedOperationException("onError is not yet supported");
                }

                @Override
                public void onNext(Integer t) {
                    out.println("" + t);
                    //N.B. no future request but Hystrix ignores this.
                }
            });
            latch.await(5, TimeUnit.MINUTES);

Consequently your probably better off not even getting Hystrix involved if your using real reactive streams and just let the endpoints deal with timeout/circuit breaking etc (ie nioSelector to nioSelector aka Netty deals with the overload itself).
I sort of googled around to see what sort of fault tolerance libraries there are for streams and I decided that there really isn't a Hystrix of streams but this probably should be a separate library because so much of this library assumes Single like behavior and not streams.

Here is the good example why Hystrix commands should support Backpressure:
    private class NumberHystrixCommand extends HystrixCommand<Integer> {

        private int number;

        public NumberHystrixCommand(int number) {
            super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("NumberThread"))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                    .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD)
                    .withExecutionTimeoutInMilliseconds(1000)
                    .withRequestCacheEnabled(false))
                .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
                    .withCoreSize(10)
                    .withMaxQueueSize(10)
                    .withQueueSizeRejectionThreshold(10)));
            this.number = number;
        }

        @Override
        protected Integer run() throws Exception {
            //emulate networking
            Thread.sleep(100);
            return this.number + 100;
        }
    }

    @Test
    public void testBackpressure() throws Exception {
        Observable.range(1, 1000)
            .map(NumberHystrixCommand::new)
            .flatMap(cmd -> cmd.toObservable())
            .doOnNext(System.out::println)
            .toBlocking()
        .subscribe();
    }

I believe this is a quite normal use-case for cmd.toObservable(). But unfrotunately, and obvious, it fails with Caused by: java.util.concurrent.RejectedExecutionException: Rejected command because thread-pool queueSize is at rejection threshold.
For this example there's easy workaround:
@Test
    public void testBackpressure() throws Exception {
        AbstractConfiguration configInstance = ConfigurationManager.getConfigInstance();
        int coreSize = configInstance.getInteger("hystrix.threadpool.NumberThread.coreSize", 10);
        int queueSize = configInstance.getInteger("hystrix.threadpool.NumberThread.queueSizeRejectionThreshold", 10)  - 1;
        int parallelism = coreSize + queueSize;
        Observable.range(1, 1000)
            .map(NumberHystrixCommand::new)
            .flatMap(cmd -> cmd.toObservable(), parallelism)
            .doOnNext(System.out::println)
            .toBlocking()
            .subscribe();
    }

There's a more interesting case with HystrixCollapser where parallel executions collapsed to single batch command. For HystrixCollapser use-case workaround is more complicated but still quite easy (assuming that we have NumberCollapserin the example withmaxRequestsInBatch=10`):
@Test
    public void testBackpressure() throws Exception {
        AbstractConfiguration configInstance = ConfigurationManager.getConfigInstance();
        int coreSize = configInstance.getInteger("hystrix.threadpool.NumberThread.coreSize", 10);
        int queueSize = configInstance.getInteger("hystrix.threadpool.NumberThread.queueSizeRejectionThreshold", 10)  - 1;
        int batchSize = configInstance.getInteger("hystrix.collapser.NumberCollapser.maxRequestsInBatch", 10);
        int parallelism = (coreSize + queueSize) * batchSize;
        Observable.range(1, 1000)
            .map(NumberHystrixCommand::new)
            .flatMap(cmd -> cmd.toObservable(), parallelism)
            .doOnNext(System.out::println)
            .toBlocking()
            .subscribe();
    }

I think that such "parallelism" could be supported out-of-the-box.
It won't affect blocking usages as soon as it will request(N), where N > 1, and blocking call new NumberHystrixCommand(10).execute() produces a single value always. With a parallel execution of blocking calls (in multiple threads, aka web requests) it will probably exceed the limits, and in this case, it's OK to throw RejectedExecutionException, but it does it already, thus nothing to be done here.

I followed your first 2 examples, and both make sense to me.  I didn't quite follow your third example - are you asking for something new in the source observable produced by Hystrix or something else?

@mattrjacobs Third example is about collapser use-case when we're using HystrixCollapser (not HystrixCommand) and, in that case, "parralelism" is multiplied by batchSize.
Thus it possible to call much more "top" collapser commands while "internal" batch commands still satisfy thread pool rejection policies

@anton-antonov I am sorry but I too might still be confused.
I suppose I somewhat understand in that you want to be able to create a stream of commands with backpressure but this is an entirely different feature than Hystrix supporting a stream of objects from a command with backpressure support. And I think you are right given the rx.Single nature of the library that your last example is more likely.
That is you want something like a HystrixCommand<HystrixCommand<Integer>> with the parent command some  how being smart about the inner command(s) which would be fairly complicated.
I still think some new sort of interface (or even library) something like HystrixCommandStream<Integer> might be better and would have entirely different semantics on thread pool creation and/or rejection... it might even block.

@agentgt Thanks. I thing, I've got the idea. In order to support backpressure, we'd need to build an outer wrapper around HystrixCommand which actually "will know" about command configuration and won't allow calling a child command more than it's allowed by thread pool policies.

@anton-antonov Bingo. And I think that it really should be a separate library. One that helps you write correct and fault tolerant reactive-stream publishers/subscribers.
To be even more candid I would seriously consider @Deprecating toObservable()  having new methods that return rx.Single aka a cold Promise.  Furthermore I would also deprecate HystrixObservableCommand as I am not sure it really provides any value. I would love @mattrjacobs input on how they use that at Netflix but it seems like an unnecessary wrapper around a true streaming Observable (for example from a Netty publisher). Just use the Observable directly.
Even more so if Hystrix were to get rewritten from scratch as a Command library it should really not have its entire core depend on rx.Java. It is the wrong abstraction for the Command pattern aka Request/Reply. In large part I think (and I'm probably wrong) Chris just chose Observable because there is really isn't any good compose-able cold promise libraries that were good in Java at the time.
TLDR it is really hard and confusing to developers to merge Request/Reply with Pub/Sub in one library and particularly in one interface. The cognitive load and confusion is just too high.

@anton-antonov Yeah, I think that's right.
@agentgt We're still in the early days of transitioning to non-blocking architectures within Netflix, so it's hard to see how it will play out precisely.  I do agree that rx.Observable is overkill for the request-reply case.
The intended use case of HystrixObservableCommand is to wrap work that's already async (a Netty HTTP client is a good example).  In this case, we're not tying up a thread, so the thread-pool isolation isn't used.  I still think that concepts like fallback, timeout, semaphore rejection are potentially useful.
One idea I'm excited about (but haven't started work on yet) is #1174.  I think that forcing an entire object upon consumers and then making them choose how to configure everything about it is not ideal.  If they could pick and choose composable behaviors, the cognitive load would be lighter.  I think we're saying the same thing.
Also, I agree with your point about distinguishing the type of work that is wrapped by Hystrix.  I think the 3 major cases I've seen are:

Request-Reply with Blocking I/O
Request-Reply with Nonblocking I/O
Request-Stream (or subscription) with Nonblocking I/O

Case 1 is handled today by HystrixCommand.  It exposes T execute(), j.u.c.Future queue(), and rx.Observable toObservable().  It lacks a single-valued, composable Future (j.u.c.CompletableFuture, rx.Single and reactor.core.publisher.Mono come to mind).
Case 2 is handled today by HystrixObservableCommand.  It exposes rx.Observable toObservable().  It lacks the same single-valued Future as Case 1.  HystrixObservableCommand wraps an rx.Observable.  It's likely more appropriate to wrap a single-valued Future.  That's tracked by #602
Case 3 is handled today by HystrixObservableCommand.  Here, it's truly appropriate to wrap an rx.Observable and get one out the other side.  In this case, the semantics of everything is different.  Should there be timeouts between emissions, only between subscription and the first?  I don't have enough experience with this yet to make a decision.  Any thoughts you have here would be helpful


Firmware 0.1.6 only telnet

I had update from 0.1.4 to 0.1.6,
after this, only telnet work.
Then I install 0.1.6 after reset, only telnet is open.
Install 0.1.4, then it work's with webinterface and rstp

Is the web interface running?

0.1.4 yes

root@yi-b82c:/home/app/script# ps
PID USER       VSZ STAT COMMAND
1 root       980 S    /sbin/init
2 root         0 SW   [kthreadd]
3 root         0 SW   [ksoftirqd/0]
4 root         0 SW   [kworker/0:0]
5 root         0 SW<  [kworker/0:0H]
6 root         0 SW   [kworker/u2:0]
7 root         0 SW   [rcu_preempt]
8 root         0 SW   [rcu_sched]
9 root         0 SW   [rcu_bh]
10 root         0 SW<  [lru-add-drain]
11 root         0 SW   [kdevtmpfs]
179 root         0 SW   [oom_reaper]
180 root         0 SW<  [writeback]
182 root         0 SW   [kcompactd0]
183 root         0 SW<  [crypto]
184 root         0 SW<  [bioset]
186 root         0 SW<  [kblockd]
224 root         0 SW   [sys_user]
231 root         0 SW   [kworker/0:1]
232 root         0 SW<  [cfg80211]
239 root         0 SW<  [watchdogd]
253 root         0 SW<  [spi0]
263 root         0 SW   [kswapd0]
348 root         0 SW<  [bioset]
353 root         0 SW<  [bioset]
358 root         0 SW<  [bioset]
363 root         0 SW<  [bioset]
368 root         0 SW<  [bioset]
373 root         0 SW<  [bioset]
378 root         0 SW<  [bioset]
383 root         0 SW<  [bioset]
402 root         0 SW   [irq/302-sunxi-m]
404 root         0 SW   [irq/166-sdc0 cd]
405 root         0 SW   [irq/303-sunxi-m]
446 root         0 SW   [kworker/u2:2]
463 root         0 SW<  [kworker/0:1H]
466 root         0 SW<  [bioset]
467 root         0 SW   [mmcqd/0]
482 root         0 SWN  [jffs2_gcd_mtd3]
487 root       980 S    -/bin/sh
528 root         0 SW   [ksdioirqd/mmc1]
531 root         0 SW   [RTW_XMIT_THREAD]
532 root         0 SW   [RTW_CMD_THREAD]
533 root         0 SW   [RTWHALXT]
534 root       680 S    ./log_server
535 root       984 S    ./dispatch
541 root     47448 S    ./rmm
575 root       988 S    /usr/sbin/telnetd
826 root       700 S    ./mp4record
837 root       844 S    httpd -p 8080 -h /home/yi-hack/www/ -c /tmp/httpd.conf
848 root       844 S    pure-ftpd (SERVER)
862 root       876 S    dropbear -R -B
885 root       844 S    ntpd -p pool.ntp.org
902 root       984 S    {wd_rtsp.sh} /bin/sh /home/yi-hack/script/wd_rtsp.sh
936 root      8036 S    onvif_srvd --pid_file /var/run/onvif_srvd.pid --model Yi Hack --manufacturer Yi --ifs wlan0 --port 80 --scope onvif://www.onvif.org/Profile/S --name Profile_0 --width 1920 --height 1080 --url rtsp://%s/
937 root      2420 S    framefinder
975 root      1400 S    /home/base/tools/wpa_supplicant -c/tmp/sd/wpa_supplicant.conf -g/var/run/wpa_supplicant-global -Dnl80211 -iwlan0 -B
1019 root       980 S    udhcpc -i wlan0 -b -s /home/app/script/default.script
1613 root      4048 S    rRTSPServer
1765 root       980 S    -ash
8328 root       980 S    sleep 10
8357 root       980 R    ps

0.1.6 was no
but after the 10th test it working upgrade from 0.1.4 to 0.1.6

Em no... 0.1.6 upgrade over webinterface was not succesfull I show them later

The log of your ps shows that dropbear is running.
You should be able to login with ssh.
Event rtsp server is running.
Check your network connection, firewall, etc...

I can't Upgrade from 0.1.4 to 0.1.6. There ist an issus.
By 0.1.6 was only telnet start. No dropbear, no httpd, no ftp. Nothing

If the cam is the same described here https://github.com/roleoroleo/yi-hack-Allwinner/issues/49 the problem could be "no space left on home partition".
Check if there are core files on /home/app.

Issue without response for 14 days.
Closed.


[fi] Use recommended names for currencies

Use Finnish names for currencies as recommended on https://kotoistus.fi/suositukset-valuutat-fi/

Thanks, Tuomas!
A question. Is it possible, that Finnish orthography prefers the original Polish letters in złoty, according to the Wikipedia: https://fi.wikipedia.org/wiki/Puolan_złoty?

Both "Puolan zloty" and "Puolan złoty" are apparently being used in Finnish, although the former seems much more common. Also, I'd consider kotoistus.fi (an expert group managed by the National Library of Finland) more authoritative source than Wikipedia, if that's what we're looking for.
Good question though. If there's a good argument for using the Polish letters I'd certainly consider that.

Thanks (in Hungarian orthographical rules, the original Latin letters are forced in this case, that is why I asked this).


Optimize rest arguments.

The TypeScript compiler generates the following code for rest arguments:
function foo(x, y, z, ...rest) {
  return;
}

function foo(x, y, z) {
  var rest = [];
  for (var i = 0; i < arguments.length - 3; i++) {
    rest[i] = arguments[i + 3];
  }
  return;
}

Although rest is unused in the body of the function, JS engines can't easily dead code eliminate the allocation of the rest array and the subsequent for loop due to the possibility of Array.prototype being mutated:
Object.defineProperty(Array.prototype, 42, { set: function() { alert(this[41]); }});

It's much easier for the TypeScript compiler to avoid emitting this code when it is not necessary.
See more details:
https://bugzilla.mozilla.org/show_bug.cgi?id=1056446

As asked by @andy-ms (here), what are the use-cases for having unused rest parameters?

This doesn't really seem needed - the overload trick is sufficient, and most people are not downleveling rest args anymore.


Patient Record - Begin Encounter - Antenatal

Issue
You will be able to immediately enter into an antenatal encounter for the selected patient from the patient record in two different ways.
(1) At the bottom of the overview screen, there is a button that will say "Begin Encounter" and this will take you to a screen where the user can select which type of encounter to begin for the patient. Only the relevant encounter types will populate. (Ex: a standard pediatric visit wouldn't populate for a 40yo)
(2) At the bottom of each progress report an "Begin Encounter" button will appear with the same flow as above.

Button Example
Begin Encounter Screen

duplicate of https://github.com/TIP-Global-Health/eheza-app/issues/76


nDays in weekOptions doesnt work

Hello!
In weekView i would like to see only the weekdays. So I added
weekOptions: {nDays: 5} to the config, but then the calendar crashes, no event appears, and no errors on console.
If I add  gridHeight: 2500 also to weekOptions, the gridHeight works perfectly, but still all 7 days appears.
screen when only nDays set in weekOptions:

screen when gridHeight also added to weekOptions:

my config:
const calendarApp = createCalendar({
dayBoundaries: {
start: "08:00",
end: "19:00",
},
views: [viewWeek, viewMonthGrid],
weekOptions: { nDays: 5 },
defaultView: viewWeek.name,
firstDayOfWeek: 1,
locale: "hu-HU",
isDark: false,
events: sessions,
plugins: [
createEventModalPlugin(),
eventsServicePlugin,
createCurrentTimePlugin(),
],
});
Versions:
Browser: Chrome Version 127.0.6533.89 (Official Build) (64-bit)
"@schedule-x/calendar-controls": "^1.42.3",
"@schedule-x/current-time": "^1.42.2",
"@schedule-x/event-modal": "^1.42.2",
"@schedule-x/events-service": "^1.42.3",
"@schedule-x/theme-default": "^1.42.2",
"@schedule-x/vue": "^1.38.1",
Expected behaviour: See only 5 days when weekOptions: {nDays: 5} set to config.

Thank you! :)


Running an Accessory on its own Host

I'm trying to stand up a single redis instance accessible by all of my roles/hosts. My goal for this issue is two-fold:

Find out if I'm missing something and need to design my architecture differently to match Kamal idioms
If (1) is not true, then identify the best approach to take when I open a PR to support my use case.

My current setup is a rails app running on my "web" host. An ActionJob worker running on a separate "worker" host, and redis running on an "accessories" host. My problem is that I cannot reach redis because (from what I can tell) there is no way to run Traefik on a host without defining a role on that host. Is this something kamal could support? Or am I missing something?

Assuming the above is a valid use case, I'd like to submit a PR to better support it. I have two different approaches in mind to achieve this:
A: Configure Traefik Container on Accessories
My first idea was to allow configuration of Traefik similar to how it can be added to non-web roles with traefik: true. This would result in deploying a traefik container to whichever host the accessory is running (if one is not present already) and binding the host's port(s) to Traefik endpoints.
B: Allow Roles to define alternative images
Alternatively, I could just deploy redis as a proper role rather than an accessory, but i'd need to be able to pull the redis image rather than using the image defined by the top-level image: configuration. This could be acheived by allowing an image configuration under a role like so:
servers:
    web:
      - <IP_ADDRESS>
    redis:
      image: redis:7.0
      hosts:
        - <IP_ADDRESS>

Which of these approaches, (or something else entirely) would the maintainers prefer I pursue? Or am I missing something blatant? (Which if so, I'd love to update the docs :))
Thanks

*sigh, nevermind. I was most certainly missing something. I had a firewall on my accessory host that was blocking redis:// requests. None of this is necessary.


Whether to reduce or not, elaborated vs. non-elaborated

Usually, the check for whether or not to reduce an expression is dependent on the reduce argument to the CompileHelper members. However, the flag doesn't always account for whether the functions are being called in elaborated mode or non-elaborated mode context. There are cases where the functions explicitly force a reduction by passing true downstream disregarding the input reduce flag. I have tried to fix this issue in currently open/blocked PR #3651, but ran into other unexpected differences.
Question: Is wrapping the reduction call sites with both both m_elabMode and reduce the right solution to disable reduction in non-elaborated mode? If not, what more need to happen?
P.S. I pointed out this issue in the recently merged PR #3758 as well but since it didn't catch your eye, reporting it as an actual issue since this needs to be accounted for in lot more other places than just this specific change.

I think we are at a state where we should not force reduction in any functions. But there might still be issues with constant propagation that needs fixing if we do so.
Forcing reduction was usually a short-term fix for some constant pushing not working otherwise.


Fix source provision

Ensure GP claims and users synced with Prod, remove direct Dropbox links to servers source

Create base worlds with min size

Postponed to next milestones


ReactionCount in ReactionMetadata doesn't decrease

As seen here, the ReactionCount is 5 when it should be 2 at this point in time: (in ReactionRemoved event handler, clicked to remove reaction from 2->1)

Actual result after clicking:

More info:
Message is 're-acquired' like so: var msg = await message.GetOrDownloadAsync();

For some reason, it suddenly works, but another time it won't. Inconsistent somehow.

@foxbot wait, so this means that this does not work properly with downloaded messages, only cached ones?


ARROW-16011: [R] CI jobs should fail if lintr picked up issues

@github-actions crossbow submit -g r


Auto update possibly prevents language server from working

I guess due to different extensions I also have installed, a rate limit for the Github API was triggered. As a result, the extension couldn't be loaded. I didn't find a way to log into Github from VSCode (or in the vscode-jsonnet settings) to circumvent the limitation. After a while I restarted VSCode and the extension worked. I only then figured, that it was the auto-update that possibly prevented the extension from being usable. For now, I have disabled the auto-update.

For further reference:
Not using custom binary path. Using default path for languageServer
Binary path is /home/user/.config/Code/User/globalStorage/grafana.vscode-jsonnet/bin/jsonnet-language-server (exists: true)
Auto-update is enabled. Fetching latest release from https://api.github.com/repos/grafana/jsonnet-language-server/releases/latest
Failed to fetch latest release from https://api.github.com/repos/grafana/jsonnet-language-server/releases/latest
rate limit exceeded


Add description on how to get perccli tool in READ.md

provision_dell_raid_overlay and provision_secure_erase_overlay require perccli tool, this PR add description on how to get a perccli tool for overlay building.

@panpan0000 @iceiilin @leoyjchang

+1


Bug: Camellia does not renew cluster info when Redis cluster is changed

We should immediately renew slots when having any node down, but currently it is not

pls see this method:
AsyncCamelliaRedisClusterClient#getClient

and see line549 of AsyncCamelliaRedisClusterClient.java
https://github.com/netease-im/camellia/blob/master/camellia-redis-proxy/src/main/java/com/netease/nim/camellia/redis/proxy/upstream/cluster/AsyncCamelliaRedisClusterClient.java

AsyncCamelliaRedisClusterClient#getClient renew when redis client == null or connection is idle right? how does camellia renew when nodes of cluster down

I means slave is promoted to master

case1: master down, slave promoted to master
master node will invalid and connect refused, so getClient method will get null for the old master node, proxy will try renew
case2: master alive, slave promoted to master inside the plan
the old master node will return MOVED reply, proxy will redirect to the new master node and try renew

many thanks


Spec table design: Add "Initial publication"?

We've designed a more simplified spec table for MDN's next generation platform. There are a few things we want to stop doing as it turned out to be bad for maintenance and bad for readers. In particular:

Links to historical specs (even implementors look up specs via MDN and accidentally reading outdated specs can be so so bad! Oftentimes these links are also useless given they redirect to the newest draft, because spec authors want to avoid people reading old specs, too).
Spec status (this outdates so fast, and adds little benefits). Also, things being in "draft" often says so little about the stability of the feature and is a bad signal to people wanting to use a feature.

For illustration, here is how we envision this to work in the future:

New spec table specification for future markdown based MDN:
Specifications are added to markdown based MDN docs by using specifications in the front matter of reference pages. Examples:
Feature defined in a single spec:
---
title: "grid-column"
mdn_url: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-column
+ specifications: https://drafts.csswg.org/css-grid/#propdef-grid-column
---

Feature defined in multiple specs:
---
title: "Date.prototype.toLocaleString()"
mdn_url: Web/JavaScript/Reference/Global_Objects/Date/toLocaleString
+ specifications:
+   - https://tc39.es/ecma262/#sec-date.prototype.tolocalestring
+   - https://tc39.es/ecma402/#sup-date.prototype.tolocalestring
---

specifications is defined as "An optional URL or array of URLs, each of which is for a specific part of a specification in which this feature is defined. Each URL must contain a fragment identifier."
(the pattern is "^http(s)?://[^#]+#.+").
Historical specs aren't added. To control which specification domains are allowed (those that qualify as relevant and non-historical) and to add human readable titles for the specs, a spec data definition file is added. It looks like this:
drafts.csswg.org/css-grid": 'CSS Grid'
tc39.es/ecma262: 'ECMAScript 262 Language Specification'
tc39.es/ecma402: 'ECMAScript 402 Internationalization API'
html.spec.whatwg.org: 'WHATWG HTML Living Standard'
w3c.github.io/webappsec-cspee: 'Content Security Policy: Embedded Enforcement'
w3c.github.io/webappsec-feature-policy: 'Feature Policy'
wicg.github.io/priority-hints: 'Priority Hints'

Non-standard features
If a feature has no spec, you explicitly state so like this:
---
specifications: non-standard
---

For now, I've rolled this out to JavaScript pages to test this design in the current wiki based MDN already and to see if we have feedback. Random pages:

Single spec: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice#Specifications (before: https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice$revision/1597030#Specifications)
Multiple specs: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toLocaleString#Specifications (before: https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toLocaleString$revision/1165291#Specifications)

I think it is a good change and now presents readers the relevant specs. However, we're loosing a piece of information here that some people are interested in: The initial publication of a feature. You were able to figure this one out in the old tables, because it showed the outdated specs, so you knew in which spec a feature appeared first. We haven't thought about this, because this is more of an advanced bit information, but MDN is also for advanced readers :) Some use cases by @ljharb https://twitter.com/ljharb/status/1220779709832630272. I agree that it does tell you something if a feature is in ES3 or in ES 2019.
So, for sure we don't want to get back to adding outdated spec links, but maybe we should add "Initial publication" to features to our spec table design? Example pages where I've added this now:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Specifications
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/from#Specifications

Thoughts? @chrisdavidmills @wbamberg @sideshowbarker @ljharb
Is "initial publication" relevant for other areas, say CSS, as well? (@rachelandrew?)

I think anything not in the spec, should link to https://github.com/tc39/proposals, and to the proposal repo; i think the stage doesn’t update that fast and so is fine to inline.
Anything in the spec should imo include the publication year, which is listed on the tc39/proposals repo as well, and won’t change.
Please do only link to the living spec on github, as that’s the most up to date.

@Elchi3 fwiw, I like this idea, although I do wonder if it is worth keeping a complete separate row for the spec the feature was initially published in, as well as the latest spec, so people can check back to see if the feature changed since it was first published?
Maybe you can just keep a single table row, and turn the spec name in the "Initial publication" column into a link to that spec?

I do wonder if it is worth keeping a complete separate row for the spec the feature was initially published in, as well as the latest spec, so people can check back to see if the feature changed since it was first published?

I'm not aware that "checking if a feature changed since it was first published" is a common use case for MDN readers. It would then provide a link to an outdated spec, which I think is anti goal here.

I think it’s mostly about giving the information one needs to configure Babel and eslint: the minimum spec year.

I'm not aware that "checking if a feature changed since it was first published" is a common use case for MDN readers. It would then provide a link to an outdated spec, which I think is an anti goal here.

I'm certainly not saying that it is a common goal, or that I'm in favour of outdated spec links ;-)
But to me it would feel a bit strange to cite a spec name without linking to it. However, if that is all that's needed (e.g. for the use case @ljharb mentions), then fair enough.

So, for sure we don't want to get back to adding outdated spec links, but maybe we should add "Initial publication" to features to our spec table design?

I think in the case of most features, the "Initial publication" spec data useful, so I would much prefer we don’t carry it forward any longer. It’s hard for me to imagine anybody actually missing it in practice once it were gone.
There are also a significant number of cases I’ve come across in MDN articles where the "Initial publication" information is just outright wrong. (I’ve corrected some of those, but there are lots more that are still incorrect.)
All that said, I recognize the “giving the information one needs to configure Babel and eslint: the minimum spec year” case that @ljharb cites for JavaScript features as something that merits addressing if we can. But IMHO the best way to address that would be by adding data for it to BCD, and maintaining it there, rather directly in BCD. That way, it would also be exposed to Can I Use and other downstream BCD consumers in a way that they could then in turn expose to their users.
And of course it could then also be exposed in MDN articles by using a mechanism similar to what’s used for the MDN browser-compat tables to pull it from BCD.
In that regard, the JavaScript-feature minimum-spec-year data (and use cases for it) seems quite similar, as a class of data, to the existing BCD compat/support data.

There are a few things we want to stop doing as it turned out to be bad for maintenance and bad for readers. In particular:

Links to historical specs (even implementors look up specs via MDN and accidentally reading outdated specs can be so so bad!

Yes. Massive +1 to dropping historical specs.

Oftentimes these links are also useless given they redirect to the newest draft, because spec authors want to avoid people reading old specs, too).

Yes, those kind of redirects get set up quite regularly. I know, because I’m the person who sets up a lot of them for W3C and WICG specs.

Spec status (this outdates so fast, and adds little benefits).

Yes. And since that status is generally set by using the Spec2 macro, it’s only as up-to-date as the source for that macro is in the kumascript repo. And if a contributor notices that the status is wrong in some particular case, they need to submit a PR to the kumascript repo to get it updated.

Also, things being in "draft" often says so little about the stability of the feature and is a bad signal to people wanting to use a feature.

Yes — the data that actually gives a useful indication of the stability of a feature is the browser-compat/support data in BCD and in the corresponding tables in MDN articles.

For illustration, here is how we envision this to work in the future:
New spec table specification for future markdown based MDN:
Specifications are added to markdown based MDN docs by using specifications in the front matter of reference pages.

I’d like to make a counter-proposal: Stop maintaining spec data directly in MDN articles and instead, let’s plan together to move it all into BCD maintain it there going forward.
The basic rationale for doing that is: It’s data.
…So let’s start maintaining that spec data as actual data — in the same way we maintain other such data in BCD, instead of directly in MDN — so that it can actually be programatically consumed as data, particularly to known downstream BCD consumers such as Can I Use.
That is, it’s the same rationale as what I mentioned in my comment at https://github.com/mdn/sprints/issues/2735#issuecomment-581584488 about @ljharb’s use case — but just more broadly applied to the spec data overall.

Longer rationale:

There are extremely compelling use cases for exposing feature spec data outside MDN articles. Can I Use is one case, but for me the one that makes it an actual necessity is the case I have for adding “MDN” annotations to all W3C and WHATWG specs — in-spec point-of-use annotations with data and links to BCD compat/support data and to MDN articles.
The WHATWG HTML spec already has such MDN/BCD annotations, and within the next few months, all WHATWG specs will have them, and all the CSS specs too, and many others.
By the end of this year, I expect that basically every spec that defines web-platform features that are documented in MDN and that have data in BCD will have those MDN annotations. That includes the ECMAScript spec. (Of course pending agreement from the ECMAScript spec maintainers;  I plan on eventually submitting a patch for enabling MDN annotations there.)
But in order to generate those MDN annotations in specs, I need the spec data in a form that I can programatically consume. Currently I get the spec data into that form by running a script that regularly scrapes (thousands of) MDN articles and then adds that spec data back into BCD.
https://github.com/w3c/browser-compat-data is the BCD fork I maintain for the sole purpose of being able to programmatically expose the spec data. The data in that fork differs from the upstream BCD data in only one way: The data for each feature has an additional spec_url key that gives the spec URL (scraped from the corresponding MDN article.)
For my purposes, I could indefinitely continue scraping MDN and maintaining that fork. But I’d really rather not have to do that.
And anyway, while that fork solves my particular information use case, it doesn’t solve the problem for downstream consumers in general. It’s imaginable that consumers such as Can I Use and the MDN Browser Compatibility Data Explorer might also want to expose the spec data to their users.
(And in fact for those particular two I’ve already opened a feature request (for Can I Use) and a PR/patch (for MDN Browser Compatibility Data Explorer) to get support added for consuming and using the spec data.)
So anyway, if we’re anyway going to be embarking on making changes to how we handle specifications in MDN, I hope we can take some time to strongly consider the possibility of moving all the spec data over to BCD.

@sideshowbarker , yes, we should treat spec data as data. We are working on what Florian calls "MDN's next generation platform", and there we plan to represent spec data as data.  See https://github.com/mdn/stumptown-content/issues/126 for some background on that.
From that perspective this conversation is really about what data exactly we should include.
About adding "initial publication": I can see the value of that for the use cases listed here, like configuring eslint. But it's worth keeping in mind: at the moment "spec data" is a generic construct across JS, HTML, CSS, etc. However we decide to satisfy this use case for JavaScript it would be nice to do it in a way that makes sense for other parts of the web platform. For example, if we represent it as "initial publication year", that doesn't do anything for CSS items, AFAIK.

@sideshowbarker , yes, we should treat spec data as data. We are working on what Florian calls "MDN's next generation platform", and there we plan to represent spec data as data.

ah, cool — looking back at the issue description, I see now that I should have realized it myself from reading that @Elchi3 had written. Anyway, given that’s the case, I’m really looking forward to seeing this get launched.

See mdn/stumptown-content#126 for some background on that.

Thanks, I glanced through that I and see y’all have put a lot of thought into this together already.

About adding "initial publication": I can see the value of that for the use cases listed here, like configuring eslint. But it's worth keeping in mind: at the moment "spec data" is a generic construct across JS, HTML, CSS, etc. However we decide to satisfy this use case for JavaScript it would be nice to do it in a way that makes sense for other parts of the web platform. For example, if we represent it as "initial publication year", that doesn't do anything for CSS items, AFAIK.

Agreed on that point. That said, I wonder if for CSS and HTML we can think of use cases for that information/data that have specific utility as clearly as the configuring-eslint case does — especially for tooling.
For CSS, I can say that I know of at least one case of an existing tool that uses CSS-version information: The W3C CSS validator at https://jigsaw.w3.org/css-validator/. If you go to https://jigsaw.w3.org/css-validator/#validate_by_uri+with_options and look at the Profile select menu, it gives you option for checking against "CSS Level 3", "CSS Level 2", and "CSS Level 1". I personally don’t understand why users would actually ever want to check against anything other than "CSS Level 3", but maybe there’s some case — and maybe there are other CSS linting tools that want to provide an option for varying their behavior based on level.
For HTML though, the current tooling I’m aware of is all version-agnostic. Or maybe rather I should say it all just follows the current HTML spec, which is version-less.
Certainly that’s the case for the current W3C HTML Checker at https://validator.w3.org/nu (which I maintain); it offers no options to check against any specific HTML version. The legacy W3C Markup Validator https://validator.w3.org/ does of course still offer options for checking against older HTML versions, though.

Yes please! For any language I want to be able to say "in this codebase you are free to use language features from version x or earlier". Having an easy way to check whether a given feature was introduced before or after x is very convenient for following such a rule. Until recently, for Javascript, MDN was that easy way. I don't want to have to say "in this codebase you are free to use language features supported by version b of browser B and version c of browser C and..." for a dozen browsers. That's hard to say and hard to check.

This does not appear to be complete at all.  For example, Promise.any still has no "initial publication" line.


Return a non-zero exit code on error

Commands such as vcpkg activate now exit with an exit code of 1 if the command method throws an exception. Previously, the exit code was always 0.

Thanks :)


Add Milestones graph to summary screen

Add a snapshot or preview of the milestones in the summary screen for the Release Plan.
We should follow the new UI design in Figma.

Duplicate of https://github.com/Azure/azure-sdk-tools/issues/6747


Fixup #2658 Intermittent failures in MongoDbTest.testTailingConsumer(…

…) and MongoDbTest.testPersistentTailingConsumer()
The tests are still failing intermittently. I have added some debug code and increased the awaitility timeout

cc @JiriOndrusek


Multiple blank task bars load

Upon starting, a metric ton of buggy taskbars load, clogging up system resources.
Screenshots

Windows version and/or build

RainbowTaskbar version
Version 2.4.1

Well that's new. Any other taskbar or shell modifications?

As far as I remember, no.

Update: I have got it to work with just my laptop alone, but with my two other monitors it does the duplicating thing.

Yeah I think I get the same issue, loads try to load for some reason then it crashes.

So it seems both of you have an issue on a triple monitor setup. Fair enough since I never got to test it with more than 2.

you guys think you could be available to try an experimental build to see if it fixes the issue? at the moment i have no way of testing a 3 monitor setup

you guys think you could be available to try an experimental build to see if it fixes the issue? at the moment i have no way of testing a 3 monitor setup

Yeah sure. Let me know.

you guys think you could be available to try an experimental build to see if it fixes the issue? at the moment i have no way of testing a 3 monitor setup

Did you mean for me to try v3.0b?


Update alert and modal implementation

This is going to be dependent on updating ReactCSSTransitionGroup to provide a callback when the animation is complete. I no longer unmount the alert ever, so the dispatch for cancellation is never fired.

Gonna close. This will also need a rebase now that postcss has been swapped in for stylus


Feature/comment block to struct

The changes look good. Should we have a unit test to check the parsing of said enum comments though ?

Good idea. I will add some.


FLANN versioning, summary fixes, drop cores

Adds to this PR ( https://github.com/conda-forge/staged-recipes/pull/218 ) for adding FLANN and pyflann to conda-forge.
This contains some jinja logic to allow for development version strings that are PEP440 compliant. They contain info about how many commits have been made since the last release and the SHA1 used for the build. The benefit of this style is works nicely for comparisons between versions. It will also make it easier to ensure the same version (using the same commit) of FLANN and pyflann are installed together.
Added some minor fixes for the summary to make the YAML parser happy.
Drops number of CPUs for make as this can sometimes be inaccurately reported by CIs.

Thanks – merged


FIxing the settings_timeout_test flake by reducing poll deadline value

You don't need to submit this PR to be able to debug and see if changing the timeout helps:
Just running bazel --bazelrc=tools/remote_build/windows.bazelrc test --config=windows_opt //test/core/transport/chttp2:settings_timeout_test --runs_per_test 100 from your windows machine should give you all the answers you need.

Here is a log from 100 runs, out of which 13 have failed (with the current timeout of 1000ms).
https://source.cloud.google.com/results/invocations/f6059109-b772-48e4-af24-0eeae8712763/targets/%2F%2Ftest%2Fcore%2Ftransport%2Fchttp2:settings_timeout_test;shard=1;run=15/log
The issue I see is that in most the latency of connect is very low in case of success  and very close to 1sec if it fails.  That might indicate a problem with the way we kick on windows - it seems that despite the socket has already connected, we don't check for the status of the socked until 1s later (which is already too late because of the 1s connect timeout) and fail. This also explains why with 2sec timeout things work fine.

Here is a log from 100 runs, out of which 13 have failed (with the current timeout of 1000ms).
https://source.cloud.google.com/results/invocations/f6059109-b772-48e4-af24-0eeae8712763/targets/%2F%2Ftest%2Fcore%2Ftransport%2Fchttp2:settings_timeout_test;shard=1;run=15/log
The issue I see is that in most the latency of connect is very low in case of success and very close to 1sec if it fails. That might indicate a problem with the way we kick on windows - it seems that despite the socket has already connected, we don't check for the status of the socked until 1s later (which is already too late because of the 1s connect timeout) and fail. This also explains why with 2sec timeout things work fine.

Indeed, when the test passes, on_connect is invoked almost immediately after starting the connection (usually <10ms later), but when the test fails, the on_connect is only called after one second. I think something is wrong with polling and we basically get the notification about successful connect too late.

Please provide:

some reasoning behind this change (analysis of what goes wrong in the test when it flakes and how is the change supposed to fix the stuff - otherwise 1 year from now when someone looks at the PR, we will have no understanding why we changed what we changed).
did you confirm this fixes the flake? how many runs have you done?

I included the following in the commit comments; let me know if you have further questions.
Intermittently (when we run the test 100 times) we see that at times
we are not notified about successful socket connection even within 1
second.
The pollset_work deadline is set to 1 second, so when our connection
timeout is also set to 1 second, we only had 1 poll.  And if that poll
didn't let us know about the socket, we didn't get another chance.
Reducing the pollset_work deadline to 100ms, now the test runs faster
and pass consistently:
result for 500 runs:
https://source.cloud.google.com/results/invocations/dd1b38f4-0f28-470b-a78b-b485445e44f2/targets/%2F%2Ftest%2Fcore%2Ftransport%2Fchttp2:settings_timeout_test/tests


[EASI-3705] Move state agency help question

EASI-3705
Changes and Description

Frontend

Moved agencyOrStateHelp from page one of opsEvalAndLearning to page 2 of generalCharacteristics
Moved agencyOrStateHelp likewise in readonly
Updated queries to new task list location
Updated unit tests
Updated cypress test
Updated translation location

Backend

GQL
Store SQL
Migration
Go data model updates
Resolver updates

How to test this change

Build containers off main

git checkout main && scripts/dev down && scripts/dev up && git checkout feature/EASI-3705_backend_move_state_agency_help_question

Insert test data

See below

Migrate data

scripts/dev db:migrate

Assert that data has migrated from plan ops eval and learning to plan general characteristics

The following columns should be moved

agency_or_state_help
agency_or_state_help_other
agency_or_state_note

Assert that the front end operates as expected, with the agency help question moved from Ops Eval & Learning to General Characteristics

PR Author Review Checklist

[x] Met the ticket's acceptance criteria, or will meet them in a subsequent PR.
[x] Added or updated tests for backend resolvers or other functions as needed.
[ ] Added or updated client tests for new components, parent components, functions, or e2e tests as necessary.
[x] Updated the Postman Collection if necessary.

PR Reviewer Guidelines

It's best to pull the branch locally and test it, rather than just looking at the code online!
Check that all code is adequately covered by tests - if it isn't feel free to suggest the addition of tests.
Always make comments, even if it's minor, or if you don't understand why something was done.

Upon creating the PR I see that we have a series of conflicts. I am resolving these conflicts now and will ping reviewers when finished.


Support rapidjson and ujson libs for better sync performance.

This adds ujson and rapidjson support. If either are found in the Python environment, they are used instead of the stdlib json library where possible. To ease installation of a compatible version of either library, "ujson" and "rapidjson" extras strings are available for the install:
pip3 install .[rapidjson]

This was work was split from spesmilo/electrumx#10.

thanks! how much faster is it?

@ecdsa the quick answer is "a little bit". Here's a benchmark script just using one of the block JSONs from the unit tests
An example run on macOS 10.14.6, cpython 3.7.7, ujson 3.0.0 and python-rapidjson 0.9.1 on an Intel i7-7920HQ:

stdlib: 7.995964743
ujson: 7.2262463100000005
rapidjson: 7.155119968999999

I am not familiar with the unit tests.. are those figures reflecting performance gain on json operations only, or on electrumx as a whole?

I am not familiar with the unit tests.. are those figures reflecting performance gain on json operations only, or on electrumx as a whole?

Fixed the attachment link. Performance gain on JSON loads operations only (i.e when we get a block or mempool blob via Core JSON-RPC)


Analysis fixture

Add a fixture analysis that has the following API:
id
The analysis database ID
set_result()
A method that sets the result field of the analysis.

can only be called once
takes a dict
also sets ready to true on the analysis document
should take effect after all files are uploaded (analysis is truly ready for viewing)

upload_file()
A method that flags a working file for upload to the server at the end of the workflow run.

arguments

name: the name displayed in the UI to the user
description: optional description for the file
path: the path to the file to upload
format: the

other features

determine and report the size of the file

Please comment @BlakeASmith

Moved to Clubhouse

Moved to Clubhouse


#records Elasticsearch::Model::NotImplemented on ActiveRecord 4.2.0 ?

class Widget < ActiveRecord::Base
  include Elasticsearch::Model
end

irb(main):010:0> Widget.search('fox').results.records
Elasticsearch::Model::NotImplemented: Implement this method in #<Elasticsearch::Model::Proxy::ClassMethodsProxy:0x0000557d573d81a8>
        from /myapp/vendor/bundle/gems/elasticsearch-model-5.0.2/lib/elasticsearch/model/response/base.rb:27:in `records'
        from (irb):10
        from /myapp/vendor/bundle/gems/railties-4.2.0/lib/rails/commands/console.rb:110:in `start'
        from /myapp/vendor/bundle/gems/railties-4.2.0/lib/rails/commands/console.rb:9:in `start'
        from /myapp/vendor/bundle/gems/railties-4.2.0/lib/rails/commands/commands_tasks.rb:68:in `console'
        from /myapp/vendor/bundle/gems/railties-4.2.0/lib/rails/commands/commands_tasks.rb:39:in `run_command!'
        from /myapp/vendor/bundle/gems/railties-4.2.0/lib/rails/commands.rb:17:in `<top (required)>'
        from bin/rails:4:in `require'
        from bin/rails:4:in `<main>'

I'm not allowed to give much more context than that.
Any general ideas on why this would be happening?
"Yesterday it worked fine".
Maybe, is there an Elasticsearch::Model method to erase ALL of the indices in the ES server?
Thanks and Kindest Regards,
Peter Fitzgibbons

That's really a weird error. Your include directive is all right. The "not implemented" exception is surprising, because the library does a bit of introspection, and picks up an "adapter" for the specific model class, eg. ActiveRecord.
Can you run this simple example with the versions you have in your application, and see it you'd get the same error?

Hi @pjfitzgibbons
Have you been able to resolve this?
If not, would you mind running the simple example linked in the comment above and see if you get the same error?
Thanks

Hi @pjfitzgibbons I'm going to close this issue. Please open a new one if you have further questions.


TEST-#2922: add read_csv true/false parameters for asv tests

Signed-off-by: Alexander Myskov<EMAIL_ADDRESS>
What do these changes do?


ci: update the prefix used in pre-validation script

Description
PR to update the prefix used in pre-validation script. Current prefix fails with:
│ Prefix must begin with a lowercase letter and contain only lowercase
│ letters, numbers, and - characters. Prefixes must end with a lowercase
      + numeric     = true
      + result      = (known after apply)
│ letter or number and be 16 or fewer characters.
│
│ This was checked by the validation rule at
│ .terraform/modules/landing_zone/patterns/vpc/module/variables.tf:15,3-13.
      + special     = false
      + upper       = false
    }

Release required?
Identify the type of release. For information about the changes in a semantic versioning release, see Release versioning.

[x] No release
[ ] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content
If a release is required, replace this text with information that users need to know about the release. Write the release notes to help users understand the changes, and include information about how to update from the previous version.
Your notes help the merger write the commit message for the PR that is published in the release notes for the module.
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

Use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author. The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).
Merge by using "Squash and merge".

/run pipeline


[Issue-3234] Fix bug not show Interlay's earning position

🚀 Deployed on https://pr-3245--sw-web-runner.netlify.app