Do not filter out stack trace for unhandled rejections

🐛 Bug Report
In strict unhandled rejections mode (https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode), the stack trace of unhandled rejection is not displayed in the console. This mode is default in Node.js 15.
To Reproduce
Steps to reproduce the behavior:

Run a test with an unhandled rejection, for example:

test("foo", () => {
  Promise.reject(new Error());
  expect(1).toBe(1);
});

The output is:

 RUNS  ./index.test.js
node:internal/process/promises:218
          triggerUncaughtException(err, true /* fromPromise */);
          ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "Error".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

Expected behavior
The stack trace is displayed in the console.
Link to repl or repo (highly encouraged)
https://github.com/vkrol/jest-unhandled-rejection-stack-trace
envinfo
  System:
    OS: Windows 10 10.0.19042
    CPU: (8) x64 Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
  Binaries:
    Node: 15.1.0 - ~\scoop\apps\nodejs\current\node.EXE
    Yarn: 1.22.5 - ~\scoop\apps\yarn\current\Yarn\bin\yarn.CMD
    npm: 7.0.8 - ~\scoop\apps\nodejs\current\npm.CMD
  npmPackages:
    jest: 26.6.3 => 26.6.3

+1

+1

Also experienced this in 15 and the downgrade fixed it.

Also experienced this in 15 and the downgrade fixed it.

This is such a frustrating default behavior.
Usually I can quickly figure out the location of the error, but today I've been working on the wrong area of my app.

Turns out the bug wasn't caused by my code changes, but an upgraded dependency in unrelated code...
I had to use VS Code debugger to trap the error. It was pretty frustrating to find all the line number details I'd expect were there. They were simply dropped by jest's output.
Is there an option to disable the stack trace hijacking? Or console hijacking?

+1

+1

Does --expand not show the full trace? If not, that's a bug

Does --expand not show the full trace? If not, that's a bug

Thanks your hint + (https://jestjs.io/docs/troubleshooting#debugging-in-vs-code) helped me solve my issue.
I am running "jest": "26.6.3" with node v15.12.0
I was using jest.fn().mockRejectedValue() that returns a Promise for a "sync" function.

@SimenB

Does --expand not show the full trace? If not, that's a bug

No, this flag doesn't help. What kind of flag is that? I can't find any mention of it anywhere?

I'm using handling it with:
process.on('unhandledRejection', (reason, promise) => {
    console.log('unhandledRejection', reason, promise);
});

in jest.setup.js

Currently, you can just use NODE_OPTIONS=--unhandled-rejections=warn yarn test to resolve this problem.

@LvChengbin NODE_OPTIONS=--unhandled-rejections=warn npm test saved me!

--unhandled-rejections=warn simply ignores the rejection, how does this resolves the problem of a missing stack trace?

@vicary it should warn, and then keep running. If you want it to warn, and then stop, use the warn-with-error-code mode (see the https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode link from the original comment)

This behavior looks consistent with the default value for Node's --unhandled-rejection option, documented here:

throw: Emit unhandledRejection. If this hook is not set, raise the unhandled rejection as an uncaught exception. This is the default.

This makes it seem like Jest has not attached an unhandledRejection event listener. It looks like Jest should be attaching such a handler here, but maybe I'm incorrectly assuming $j.process is analogous to the process global.

We found a solution, although I am sure it has a performance impact.

This behavior looks consistent with the default value for Node's --unhandled-rejection option, documented here:

throw: Emit unhandledRejection. If this hook is not set, raise the unhandled rejection as an uncaught exception. This is the default.

This makes it seem like Jest has not attached an unhandledRejection event listener. It looks like Jest should be attaching such a handler here, but maybe I'm incorrectly assuming $j.process is analogous to the process global.

They do attach it. But if you look carefully they restore it after the tests are complete. So what is happening is the tests are completing, they are restoring the (non-existant) event handlers, and then node is blowing up. Since the promise is rejecting after the test suite finishes.
We found a workaround, by flushing the promises after each test, the error is forced to happen exactly where the test fails, and it even marks the test as failed. I am sure it will have a performance impact, so I am testing that a bit.
https://www.npmjs.com/package/flush-promises
const flushPromises = require('flush-promises');

afterEach(async ()=>
{
    try {
        await flushPromises();
    } catch(e) {
        console.log(e);
    }
});

@timritzer ah, nice find! That matches up with the fact that the following code will produce an error handled by Jest when await new Promise(...) is there, but will produce an unhandled promise rejection when it's missing:
it('example test', async () => {
    Promise.reject(new Error('error'));
    // Comment out the following line to see an unhandled rejection error
    await new Promise(resolve => setTimeout(resolve, 0));
});

Yep! Also just did some before/after testing on our admittedly small test base of ~600 tests and 5 snapshot tests. Performance difference was pretty minimal. Ultimately it's just an empty promise that resolves so I can't imagine it will have too much overhead.

I did a little more digging - per the Node source code, it looks like Node should be printing a proper stack trace for uncaught exceptions, as long as the rejection reason is an instance of Error:
https://github.com/nodejs/node/blob/09c9e5dea42fd11606f0d8988462e291cbfafd32/lib/internal/process/promises.js#L244
However, for some reason, it seems like errors that are thrown in Jest code aren't actually errors. You can reproduce this easily with the node interpreter. Compare the output of the following scripts:
$ node -e "Promise.reject(new Error('this is an error'));"
[eval]:1
Promise.reject(new Error('this is an error'));
               ^

Error: this is an error
    at [eval]:1:16
    at Script.runInThisContext (node:vm:129:12)
    at Object.runInThisContext (node:vm:305:38)
    at node:internal/process/execution:75:19
    at [eval]-wrapper:6:22
    at evalScript (node:internal/process/execution:74:60)
    at node:internal/main/eval_string:27:3

$ node -e "Promise.reject('this is not an error');"
node:internal/process/promises:246
          triggerUncaughtException(err, true /* fromPromise */);
          ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "this is not an error".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

The former (which is an actual error) includes a very nice and easy to understand stack trace; the latter (which is not an error) shows the reference to Node internals that the original report in this thread shows. I'm not sure why an error isn't seen as instanceof Error by Node - it could be the fault of Jest, or some unknown polyfill, or something else. But this seems to be the root of why we don't get nice stack traces in Jest.
Interestingly, if you add the following to a script referenced from setupFiles, Node does show a nice stack trace - presumably the default uncaughtException handler is behaving better than the default unhandledRejection code.
process.on('unhandledRejection', (reason) => {
  throw reason;
});

To explain the "why" at least: Promises do not throw errors on rejection (and never have). Instead, all they do is generate a new, completed promise with the rejected flag set and the rejection data bound so you can get that data out. Rejections themselves are in fact the opposite of an error: they're one of the two well-defined ways in which a promise is expected to complete. However, if something doesn't handle a promise rejection, that's an error and you get an UnhandledRejection error.

I think I've narrowed this down to an issue with Jest's jest-environment-node (possibly other environments as well). I added the following log below this line in the Node environment implementation:
const require('console');
console.log('Error prototypes equal? ' + String(Error === global.Error));

When I run Jest, I see the output Prototypes equal? false - which explains why Node doesn't think the promise rejection reason isn't actually an Error and thus doesn't print the error with its stack trace.
As for a fix... let's consider the following simple test case:
describe('index', () => {
    it('has unhandled rejection', () => {
        Promise.reject(new Error('error in test'));
    });
});

If we run that with the latest published version of Jest, we'll see the [UnhandledPromiseRejection ... error without a stack trace.
Now, let's add the following line below this line in the Node environment implementation:
global.Error = Error

Now when we run the above test, we see the actual stack trace:
$ jest --runInBand

 RUNS  src/index.test.js
/path/jest-unhandled-rejection-repro/src/index.test.js:3
    Promise.reject(new Error('error in test'));
                   ^

Error: error in test
    at Object.<anonymous> (/path/jest-unhandled-rejection-repro/src/index.test.js:3:24)
    at Object.asyncJestTest (/path/jest-unhandled-rejection-repro/node_modules/jest-jasmine2/build/jasmineAsyncInstall.js:106:37)
    at /path/jest-unhandled-rejection-repro/node_modules/jest-jasmine2/build/queueRunner.js:45:12
    at new Promise (<anonymous>)
    at mapper (/path/jest-unhandled-rejection-repro/node_modules/jest-jasmine2/build/queueRunner.js:28:19)
    at /path/jest-unhandled-rejection-repro/node_modules/jest-jasmine2/build/queueRunner.js:75:41
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

This isn't perfect - for instance, it doesn't handle someone rejecting a promise with a TypeError or any other class that inherits from Error. If we change the above simple test case to Promise.reject(new TypeError('type error in test')), we're back to the same uninformative error as before:
$ jest --runInBand

 RUNS  src/index.test.js
node:internal/process/promises:246
          triggerUncaughtException(err, true /* fromPromise */);
          ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "TypeError: type error in test".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

Copying over the TypeError prototype to the new global object fixes this too, but this feels like playing whack-a-mole. I don't understand Jest environments to know if this is the right fix, or if there's something else that would work better instead.
FWIW, it looks like there's precedence for this kind of change. For instance, https://github.com/facebook/jest/pull/7626 copied over the ArrayBuffer prototype to the environment so that Buffer.from([0x62, 0x75, 0x66, 0x66, 0x65, 0x72]) instanceof ArrayBuffer would be truthy.
@SimenB does this seem like the right fix? I'd be happy to make a PR if so.

I've opened a bug for nodejs: https://github.com/nodejs/node/issues/41676
Seems like it's a much deeper problem

Hey, saw this in the Node repo
Pull request based on @ItamarGronich 's issue in Node: https://github.com/nodejs/node/pull/41682
We likely won't fix the issue of primitives throwing (also raised there, at least I'm personally -1 but other members may feel differently) but I've altered the check for unhandled rejection error logging to check if the error has a .stack property rather than instanceof Error to deal with cross realm errors.
As mentioned previously you can use the 'unhandledRejection' event (on process) to work around it in the meantime. When I designed the hook it was meant to be versatile and enable this sort of use case, you would set it up in globalSetup for example you may choose to:
process.on('unhandledRejection', (reason) => {
  console.log(reason); // log the reason including the stack trace
  throw e;
});

Even if that PR might land soon, it might be worth updating the docs for now to explain this use, in an easily discoverable location with links to it from other obvious places people will be looking. Worst case, the docs can be reverted a few days from now, but some Node PRs end up taking months of back and forth, and then having those docs updated will make a huge difference to a lot of people =)

The PR landed yesterday and will go out with the next v12/v14/v16/v17 versions.
Probably a good idea to update the docs regardless.

Happy to take a docs PR 🙂

Not stale

Stale, stale, this was fixed for every non end-of-life version of Node.js :) @cameron-martin

Oops, somebody close it then


Cancel calls

(Note: depends on https://github.com/crossbario/txaio/pull/137)

All CI will fail until there's a txaio release with cancel support


Clicking the second element found

Hi all, im writing a test scenario where i need to click a button (simple right?) the thing is that there is another button in the screen that is identical to the one i want to click.
After a lot of searching online i have found that protractor allows to specify what element  you would like to click (or any other action) using-
element.all(by.css("button")).first() or .last()
Does CodeceptJS support such functionality ? any help would be great :)

If you dig into the helpers documentation you can find the click directive.
http://codecept.io/helpers/WebDriverIO/#click
I.click({css: '.parent button:first-child})

Currently you can use XPath or CSS to point to the first or last elements.


Question: How to best deal with missing labels?

I tried using FAMO and it seems to work well, for batches with no labels for a task I am setting the task  loss to 0. Any better approach you would reccomend?

Thanks for reaching out. Setting task loss to 0 is one solution. Another possibility I can think of is to keep a buffer of data for each task, and update the buffer with the most recent data from the new batch (like having K queues for K tasks). Then you can replay from the buffer to do the update so that we ensure there is always some data for a certain task.

Thanks for replying, I guess that would be somewhat equivalent to sampling the batches so that they always have representatives from each task rigth?

Yes, it should be similar, but if that is not doable, you can use the replay buffer idea under scenarios like online learning (using reservoir sampling for instance). This is also similar to the replay buffer idea in RL.


Monitor Electric Vehicule charger SE inverter

Hello.
One of my SE inverter is a EV charger and I wonder if we could read the power sent to the car as an independent load, this way we could read how much energy we are "using and storing" in the car.
Would this be possible? How could I help make it possible?

I'm not aware of any registers for that (or other) devices, so no, not through this integration.
I would recommend getting a separate branch circuit monitor for that data.


:package: Feat: Add @evmts/cli package

Description
Add evmts/cli package to do following actions

create-evmts-app
add-evmts
generate code
typechecking

Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #650   👈

This stack of pull requests is managed by Graphite.


🌱 logicalcluster deletion: switch to .Cluster()

Summary
Switch the logicalcluster deletion code to use .Cluster() instead of the context-based RoundTripper.
Related issue(s)
Fixes #

/approve


Bind ExRouteAdapter instance to render callbacks

https://github.com/aksonov/react-native-router-flux/issues/229

Sorry, but it could brake existing apps. Why binding to this.route is not enough for rendering?

I'm quite positive this is a bug but I'm not sure where to fix it.
I found that in the constructor of ExRouteAdapter, on this line, title is set correct for the ExRouteAdapter instance but not the Route. Updating my PR to show you.
I really have no idea how this should be solved, you think you could help me?

Looks like the problem that Route doesn't update their props during actions. Then probably we have to fix BaseRouter. It should modify stack route with latest props, could you check there?
For example:
    _push(name:string, props:{ [key: string]: any} ){
        this._stack.push(name);
    }

Probably it should be added :
this.routes[name].props = Object.assign({}, this.routes[name].props, props);

What do you think? I don't have much time now to add such calls for all action types, check if everything is OK with demo, maybe someone could check.

@danielweinmann Could you look it? I still don't like your fix when you rebuild whole route stack for new props coming from Router, maybe it would be more correct to fix BaseRouter and set new props after each action there?

@aksonov I'll try to take a look later this week!
About your suggestion, I don't think after new action is a good enough place to set new props. It's important that every react component re-renders when receiving new, different, props.
No matter what they know about their own state, thinks can change on the outside and shouldn't have to dispatch an action to change.
I'm still guessing the main reason you guys don't share my line of thinking is because you all must be using a big root router that manages a whole app. Is that right? In my case, I have a lot of state management without any route and a few small routers deep inside my rendering stack. This makes sense for me, since I only want to have a router when I need navigation functionality, and in a big part of my app I don't need navigation. It would mean a lot on unnecessary code to have a big root router.
So I need a way to do just that: rebuild the whole stack for new props coming from Router.
PS: I still don't like my solution in terms of elegance of the code. But it solves this scenario, and any other solution presented so far don't.
PS2: I think when @MITDelian finishes making BaseRouter immutable we will see more clearly how to make my solution better.

Closing it for now because of 3.0 release is published.


Multiple behavex commands resulting in a single HTML report file

Hello,
First, thank you for your work on this package!
I am in a situation where I run multiple behavex commands one after the other. This is because I have to test a software with configuration A, run my test which have the tag @conf_A, restart the software in configuration B, run my tests which have the tag @conf_B and so on. This results in multiple HTML reports / pages. I have made an kind of a home page with a link to each index.html page generated by each behavex command to facilitate the navigation between the tests results.
I am wondering if there would be a way to have all the results of the test in a single index.html page ? This would make the reading of the execution reports much easier.
Thanks again :)

Hi Pierre, we had this functionality in the past, but it has been deprecated due to the complexity of merging all the evidence. However, we will keep in mind re-implementing the script to merge reports.
Thanks!

Sorry to jump in. But I really don't think this is some feature, we would like to have. but if you really want to bring it back, please implement using a switch whether we want to have old reports merged or not !

It surely would be useful to have a option to merge final report into a single standalone html file that can be easily shared and hosted by a stateless web service like gcp's cloudrun.


Is reloading of modules possible?

Like somehting equivalent to :reload in ghci possible in IHaskell?

I usually restart the kernel and run all cells to achieve a similar effect.

Closing this, please reopen if required.


[DOC] Remove experimental flag in Security Analytics documentation for 2.5

The experimental banner has been removed in the Security Analytics UI for version 2.5. The experimental warning note needs to be removed from documentation as well.

[x] Request a change to existing documentation
[ ] Add new documentation
[ ] Report a technical problem with the documentation
[ ] Other

Tell us about your request.
Remove the experimental feature warning from the About Security Analytics section. This warning note, by the way, also includes a link to the forum. So I'll roll that information into the"Resources and information" heading that follows the note.
What other resources are available?
About Security Analytics

This was merged in #2401. Closing this issue.


[rv_dm] write and read pointer are reset differently

If LC is in RMA or TEST_UNLOCKED, it's allowed to switch taps without issuing reset.
When we switch taps from RV_DM to LC, trst_n is driven to 0, which resets write pointer, while the reset of write pointer isn't asserted as it's from internal reset. Hence, these 2 pointers are different which causes RV_DM to fetch the fifo and start a transaction.
Then, when switching back to RV_DM tap again, jtag access doesn't work correctly.
related to #12461
cc: @cindychip

@weicaiyang this issue should be fixed now.
let me know if you still run into problems. If not, feel free to close this.

Thanks @tjaychen
close via https://github.com/lowRISC/opentitan/pull/12613


Azure sites - Added Permission to do start and stop

Hey, I just made a Pull Request!
This PullRequest will fulfill feature #16035 - Protect start & stop Azure sites.

:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

@benjdlambert / @vinzscam Can you re-trigger the pipeline CI / Verify 20.x (pull_request) its failed for different reason.

@deepan10 this needs rebasing now anyways as it looks like there's a conflict. Please rebase with the mainline and re-push

@vinzscam / @benjdlambert anything else needs to be adjusted or improved in this PR?

@backstage/permission-maintainers  can I get a co-review of this please to see if this seems sane? :pray:

Hello @vinzscam  / @benjdlambert,
All the review comments were addressed and the pipeline line failure don't relate this change.

great job @deepan10 👏


BUG: When logging in it asks you to choose a subdomain name again

When I login at website.univerese.app it always bring up the "Select Your Personal Sub-domain name" page (see screenshot below). You have to hit "cancel" to get to the editor.
This recently confused a new website builder client, Jana, and it also is bothersome for me even. It would be nice to just go to the builder if you've previously set up your account.

fixed IIRC


C: indentation: incorrect with '' immediately after '/'

~jbowler/vimrc:
set exrc
set secure
set highlight=lb
set shiftwidth=4
set softtabstop=-1
set expandtab
set undofile
filetype plugin on
filetype indent on
directory .vimrc:
set textwidth=80
file (test.c):
{
first line;
second/bug/*line;
}
'o' on the second line.  Insert a space between the */ and the * and 'o' indents correctly.
Gentoo:

Searching for vim ...
[IP-] [  ] app-editors/vim-8.0.1188:0

I think that's all you need; jbowler long term resident acm.org for more info.

Oh, the lines on the test file do need to be indented.  They were in the text I c'n'p'ed but some HTML gurfuss decided the indentation wasn't required.

John Bowler wrote:

Oh, the lines on the test file do need to be indented.  They were in the text
I c'n'p'ed but some HTML gurfuss decided the indentation wasn't required.

I see the problem I'll make a fix.
--
|
Ceci n'est pas une pipe.
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


Zeroswap

Adding Zeroswap DEX

Please, update the GitHub repo link, currently isn't working.

No updates were received. Feel free to open it with complete information.


Can not zoom to entities when globe is not displayed

The following (working!) sandcastle creates an entity and zooms to it, using viewer.zoomTo(viewer.entities):
https://sandcastle.cesium.com/index.html#c=bZFRS8MwFIX/yqVPFWrSuuqw64ayPQo+THwKSNbe1WCajCTd2GT/3TTdROYogXtu7/lyeltpZR1sBe7QwBQU7mCOVnQteQ+9mEVV0HOtHBcKDYsS+GYKgNJG6hUWsObSYsLU8WbCFFNVQG60FU5o5aEn4Jwb5yuuRmRtdLvAxiDauEfdZncjko7z/CF7TPpGnpP0Ph2N04cgszRNmerxAxyVE27v0UNwErRAS3hdxyHc+fritwqgVtcoiyE/QGdEASwihC55u5G44I7TMGLpEPpZmFP14UvSyBWLeu/x/LmnAAet2zcdX8QZ9tE/URKxaNI7zwegtG4vcTYIgCfRbrRxPpSMfSKHPhH3C6OrrvpCRyobeMFJ/1rLWmxB1NMrfwoqya31b9adlEtxQBbNSurn/1ml5rVQzesWjeT7fuwzm70MTUJISb287nRayxU3F+Qf
However, when UN-commenting the line that sets
globe: false,
for the viewer, it creates an error message:
TypeError: Cannot read properties of undefined (reading 'ellipsoid')
    at ModelVisualizer.getBoundingSphere (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:143767:29)
    at DataSourceDisplay.getBoundingSphere (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:146162:32)
    at updateZoomTarget (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:217126:47)
...

This is caused by this line in ModelVisualizer.js that accesses the globe and its ellipsoid:
  const globe = scene.globe;
  const ellipsoid = globe.ellipsoid;

Note: A fragment like const ellipsoid = globe.ellipsoid; appears in several other *Visualizer classes. Some of them do check whether the globe is valid. Others may not. This has to be investigated. (Another questions is why obtaining the bounding sphere of a model requires the globe and its ellipsoid, but that might be beyond the scope of this issue)

hello javagl
In which file i can find the code related to this issue

@gaurav8y785675474 I pointed to the file/line https://github.com/CesiumGS/cesium/blob/828d6799916196a6f9c79dd8e5b001d58305e093/packages/engine/Source/DataSources/ModelVisualizer.js#L382 , but mentioned that there may be multiple files or places where the same error could happen.
As part of solving this issue, someone will have to look for places where scene.globe is accessed, and make sure that the case that the case where no globe is present is handled appropriately. Basically,
if (!defined(scene.globe)) {
    // There is no globe. You'll have to think about what to do here.
    // (In some cases, it might be as simple as using a default ellipsoid.
    // in other cases, it may be more tricky...)
} else {
    // Do whatever you want to do with the globe...
}

I'm not sure whether this issue should be reopened, or whether this should be traced in a new, more general issue.
(For now, I could only describe that general issue as: There are quirks when globe=false, and various places. And someone should go through the code, and review this. This may even start pragmatically, by doing a full-text search for globe. and make sure that there is a defined check each and every time that the globe is accessed....)
Specifically: In the demo sandcastle of https://sandcastle.cesium.com/?src=3D Tiles Photogrammetry.html , adding a globe: false will cause a TypeError ... undefined.
I know, one can argue about that, and maybe say that setting a terrain together with globe:false does not make sense. But this is not apparent from the documentation, and even if it was, it should be handled by saying: "ERROR: That doesn't make sense" at construction time, and not at some random later place...
What's particularly surprising is that this is caused in the line https://github.com/CesiumGS/cesium/blob/cd5d6087d4c605a5a81da1a38894792350628df3/packages/engine/Source/Scene/Scene.js#L4402 , which could trivially be wrapped into a defined check, and a few lines above that, that exact defined-check is indeed applied!


Should auto-approve always be set to true?

Is there ever a case where the auto-approve flag should be set to false? It seems to control if the CLI should be in interactive mode or not, and the mixin always needs to run in unattended mode. In other mixins, we have been setting flags that always need to be set automatically for the user. If that's the case for this flag here, I suggest that we just set it inside the mixin and not expose it.

See the glcoud mixin's flags, which are hard coded to always run in non-interactive mode
https://github.com/deislabs/porter-gcloud/blob/2f418ee71d76af62a619b3d7d87a89561de235fe/pkg/gcloud/action.go#L64-L65

Per conversation offline, the spec (core 1.0) doesn't support any way for bundles to have an interactive confirmation prompt. So mixins should always set flags to run the commands in a non-interactive / quiet mode.


Added CVE-2016-0808

Hi,
This pull request contains the check for CVE-2016-0808
cve20160808.c in jni
CVE_2016_0808.java in framework/graphics
vuln_map.json
VulnerabilityOrganizer.java

Thank you for your contribution.  I've made some inline comments.  Also, you may want to consider using binmatcher: https://github.com/nowsecure/android-vts/blob/master/app/src/main/java/fuzion24/device/vulnerability/vulnerabilities/framework/media/CVE_2015_6616.java#L61
This avoids having to use native code here, which i've been trying to do whenever reasonably possible

Thanks for your feedback!
I added some explanation about the details of this CVE in cve20160808.c.
I will try to avoid using native code next time.

@kayji would you mind rebasing this on the current master?  Thanks.

I'll start working on that soon.

awesome, thank you.

Not sure what happened to this. I have done a rebase on the current master branch here:


Update sort command in UG/DG

Updates to be made to (but not limited to) user stories, use cases, implementation, features sections.

tagging myself just for fyi that am working on the sort command related sections atm! :)


Reuse of list parameters is not working

When registering a list parameter e.g. with entityViewSetting.addOptionalParameter("listParam", list) and reusing this parameter in multiple spots in a query like .inExpressions(":listParam"), the query execution fails because not all parameter indices seem to be bound.
Workaround is to register a fresh parameter in every use site, e.g. with .in(list).

Can't reproduce the error. If you run into this again, please attach a testcase for it.


Improve hover in Call Hierarchy UI

Our language server provides useful information as the detail of CallHierarchyItem,
but that is often too long to be presented fully in the narrow side bar.
So, some users ask to trim down info included in the details (e.g. https://github.com/golang/vscode-go/issues/2057)
but I don't think that's the right approach. When function names are rather long, the details are completely hidden.
The current call hierarchy UI seems to use only name for its hover message.

How about adding the detail info to the hover message, too?

@jrieken I've just submitted a PR for this.


fixes for 2293 and 2361

2361
added #b3b3b3 border to search field
2293
removed last 3 "oceanNodes"
swapped out homepage video banner image
Also...
_base.sass: fixed 2 loose commas
index.html: deleted dead vendorStrip code

This change is

I signed it!

@CreaturesInUnitards Can you make sure you signed the CLA using the same email address as is associated with your GitHub account? Thx

Weird. Still waiting on you to sign the CLA.  It's different from the google CLA you signed originally.  Can you verify that it's signed?

Ok signed it again — apparently my profile update didn't take the first time :/

@CreaturesInUnitards Thanks for signing the CLA.
The preview for the main page looks off. Removing the 3 "oceanNodes" but leaving the video leaves a strange blank space in the middle of the page.

Not sure why the CLA is no longer valid.

@CreaturesInUnitards Should I just close this for now until we can decide how to refactor the home page?

@chenopis I'm no longer with United Creations, and therefore no longer on this project. If Bob Hrdinsky is still leading the marketing effort, I'd probably run it by him.

@CreaturesInUnitards Ok, thanks for letting me know. I'm going to have to close this PR for now then.


PatchLinks + boost::serialization broken with loadRegion()/saveRegion()

The older GridVecConv could cope with boost::serialization, but the current implementations of  loadRegion()/saveRegion() cannot.

Uglyness of the current solution:

SerializationBuffer is untidy
changes required to StripingSimulator so buffers of variable size can be transmitted/received
Duplicate code for load-/saveRegion() in Grid and DisplacedGrid
ATM not supported by CUDAGrid/CUDASoAGrid/SoAGrid

Also currently unsupported: UnstructuredGrid/ReorderingUnstructuredGrid


Fix gitlab functional tests

Merge .gitguardian.yml into .gitguardian.yaml and remove .gitguardian.yml.
Having both causes .gitguardian.yaml to not be loaded, causing the tests/functional/test_docker_image.py tests to fail (they did not fail in the PR because the test clones ggshield main branch).

Codecov Report

Merging #632 (c9162d2) into main (0fc99bc) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #632   +/-   ##
=======================================
  Coverage   93.98%   93.98%
=======================================
  Files         103      103
  Lines        4804     4804
=======================================
  Hits         4515     4515
  Misses        289      289

Flag
Coverage Δ

unittests
93.98% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


Fix incorrect BigQuery schema creation from FeatureSetSpec

BOOL value type in FeatureSetSpec is registered as repeated mode in BigQuery, because of incorrect comparison of the type Enum. It should be a single (non repeated) mode.
The comparison:
https://github.com/gojek/feast/blob/1ef1b712b56c00504f37fa4396ed1ebdce625f6a/ingestion/src/main/java/feast/ingestion/utils/StoreUtil.java#L121
The proto for the enum:
https://github.com/gojek/feast/blob/1ef1b712b56c00504f37fa4396ed1ebdce625f6a/protos/feast/types/Value.proto#L34
This pull request:

Add a test to ensure correct BigQuery schema is created.
Compare using the enum name suffix versus the enum int value. This makes the comparison more explicit.

/lgtm


fix: Properly set ubi8 tag during the release process

Also we set all the related UBI text to UBI8 so we clarify which version of UBI
we're talking about when running the CI/CD and any file

/ok-to-merge CI changes


gitbook.com links are all broken

It looks like nuts.gitbook.com doesn't exist, all the links from the README are leading to server not found errors.

Is this why the "deploy to Heroku" button doesn't do anything on Heroku for me?

Seems to be working now

Deploy to Heroku button still fails for me... can anyone else confirm?


How to create a web session with a pod/service?

Is there any way to initiate a web session with a running pod/service in order to provide realtime-interactive web service?

What do you mean with session? Cookies?
Isn't it default, or how you configure the web app?

I don't think this is a k8s-on-arm issue. You'll probably find information how to do this from mainline k8s or the web.
Reopen if it isn't working, and it's a ARM issue


update(cmake): bump plugin versions

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

/kind release

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area engine

/area tests

/area proposals

/area CI

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: loresuso
Once this PR has been reviewed and has the lgtm label, please assign mstemm for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/milestone 0.35.0

Yeah ofc, I was just waiting :)

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: ae9bc13bccf1114710ff107f74ef482201136e8e

At line 17:
set(PLUGINS_DOWNLOAD_BUCKET "dev")

Should be set to "stable".

New changes are detected. LGTM label has been removed.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, jasondellaluce, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: fc2ebff03b6436d601f6fe3521e3ceda18449eb0

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: FedeDP, jasondellaluce, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


typing.TypeAlias & typing.Annotated

Right now, this plugin will not allow the following code:
from typing import Annotated

SpecialInt = Annotated[int, "Very important metadata"]  # Y026 Use typing_extensions.TypeAlias for type aliases

Is this correct behaviour? What is the interaction between PEP 593 & PEP 613?

I suppose this is intended behavior, since SpecialInt = int should also be annotated with TypeAlias according to Y026.

Yes, that's correct. The code you posted should use TypeAlias.


Relax propType check for RiskBubble risk level

Warning in development mode:

null is a valid value according to the component code and what's in the database, so making this prop required doesn't make sense.  What we really want is "you must pass the prop as a key, even if the value is null or undefined," but that's not what .isRequired means.

selfie


Show summary of changes for deploy

Warn Checklist

[ ] This changes the interface and requires a Major/Minor version change.
[ ] I have :tophat:'d these changes by using the commands I changed by hand.
[ ] I have added a dependancy to the project.

@tanema this appears to work, but I'm getting some DATA RACE warnings in the tests, e.g.:
==================
WARNING: DATA RACE
Read at 0x00c0000247c8 by goroutine 41:
  github.com/Shopify/themekit/cmd.download.func1()
      /Users/andyw8/src/github.com/Shopify/themekit/cmd/download.go:60 +0x799

Previous write at 0x00c0000247c8 by goroutine 39:
  github.com/Shopify/themekit/cmd.download.func1()
      /Users/andyw8/src/github.com/Shopify/themekit/cmd/download.go:60 +0x7b5

Goroutine 41 (running) created at:
  github.com/Shopify/themekit/cmd.download()
      /Users/andyw8/src/github.com/Shopify/themekit/cmd/download.go:46 +0x337
  github.com/Shopify/themekit/cmd.TestDownload()
      /Users/andyw8/src/github.com/Shopify/themekit/cmd/download_test.go:28 +0x437
  testing.tRunner()
      /Users/andyw8/.dev/go/1.12.9/src/testing/testing.go:865 +0x163

Goroutine 39 (finished) created at:
  github.com/Shopify/themekit/cmd.download()
      /Users/andyw8/src/github.com/Shopify/themekit/cmd/download.go:46 +0x337
  github.com/Shopify/themekit/cmd.TestDownload()
      /Users/andyw8/src/github.com/Shopify/themekit/cmd/download_test.go:28 +0x437
  testing.tRunner()
      /Users/andyw8/.dev/go/1.12.9/src/testing/testing.go:865 +0x163
==================

I haven't dug in deep yet, just pinging in case there's something obvious that I've missed.

@tanema seems I'll need to use atomic functions for handling the incrementing, so looking into that.

cc @Nupur-Mukherjee for any thoughts on this suggestions.

@andyw8 I agree with @tanema
Lets use "No change in" in place of "skipped" for more clarity.


Option to Disable Shortcut

Hi, is it possible to have a flag to disable the shortcuts?
I have a scenario where the user might need to type "{{my_custom_tag}}" in a textbox, and thus the underline shortcut will trigger the zoom out without intent.
Thanks for the plugin,

the plugin is really easy to understand.
if you can give us a PR this will be very helpful.

Hi, I'm sorry, I tried but I could not manage to run the original code on my machine, so I cannot test if it works if I do any change.
If you could please do the change....
pluginsOpts:    {    [zoom]: {       zoomInKey:  ['ctrl', 'a'],       zoomOutKey: ['ctrl', 'b'],    } },
I get this error on the [zoom] line:

error TS2464: A computed property name must be of type 'string', 'number', 'symbol', or 'any'.

By the way those variables are not doing anything in the code: zoomInKey and zoomOutKey

currently zoom keys are in development but you can zoom things whin Shift + and Shift -


Refs #34799 - Skips cross-schema relations with inspectdb when using MySQL

Problem
We use inspectdb to generate models for a legacy MySQL database whose tables include cross-schema foreign keys (the MySQL instance uses schemas to namespace tables, but they all belong to the same system).
A change to the inspectdb command that was released in Django 4.1 broke generating models for these tables: https://github.com/django/django/commit/aaf9b558583d9bb75a0c9d53b135dc8c1b75b6a2#diff-e4bb601306bc4dba91357e4235d394d008c9e582f5b4d146b9c93c80924a75d4R124
More details in the ticket: #34799
Solution
Modify the MySQL backend's introspection code to ignore cross-schema foreign keys. I've added a test that runs when the DB connection is on MySQL. Example settings and docker-compose here:
https://gist.github.com/johnjameswhitman/f500d385486b529fa4d1616a6cc9175d

Should I also add a note somewhere in docs/releases/? I don't think this bugfix is backwards incompatible, but happy to add a note for visibility.

@felixxm -- thanks for the review :pray: I think I got to all of your comments. One weird issue I ran into was that if both of the new cases were in the same test-class and I ran them both in a run I got some kind of transaction error (below). Splitting them into their own classes fixed the issue.
$ ./runtests.py backends.mysql.test_introspection.TestCrossDatabaseRelationships --settings=test_mysql
...
Traceback (most recent call last):
  File "django/tests/backends/mysql/test_introspection.py", line 103, in test_get_relations_omits_foreign_schema_relation
    raise e
  File "django/tests/backends/mysql/test_introspection.py", line 91, in test_get_relations_omits_foreign_schema_relation
    other_cursor.execute(
  File "django/django/db/backends/utils.py", line 77, in execute
    return self._execute_with_wrappers(
  File "django/django/db/backends/utils.py", line 90, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "django/django/db/backends/utils.py", line 95, in _execute
    self.db.validate_no_broken_transaction()
  File "django/django/db/backends/base/base.py", line 517, in validate_no_broken_transaction
    raise TransactionManagementError(
django.db.transaction.TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block.

@johnjameswhitman Thanks :+1: Welcome aboard :boat:
I combined both test methods.

Thanks again for the review @felixxm. Two quick questions:

Do I need to do anything else to merge this? It doesn't look like I have permissions to merge myself, so figure it may be in your hands now.
Do you know which version(s) of Django this will be released with?

1. Do I need to do anything else to merge this? It doesn't look like I have permissions to merge myself, so figure it may be in your hands now.

No, merged.

2. Do you know which version(s) of Django this will be released with?

5.0


Runner requires Python 2

Python 2 is becoming increasingly unavailable.  I think it also depends on an unspecified older version of psutils for the asm.js benchmarks.

@athas This code is unmaintained. So if you want to have Python 3 support (and more recent psutils), you can fork and update it yourself :-).


Actor crashed - network_ready - container went missing

I'm not really sure what is going on here but I'm seeing lots of fatal errors in my kontena agent logs and I cannot deploy services because of them...
I upgraded to 1.3.5 and am trying to setup a firewall to lock down weave, of course using a docker container:
stack: firewall
version: 0.5.1
description: Global firewall services

variables:
  # A comma-separated list of IPs to allow for Weave
  firewall_weave_static:
    type: string
    from:
      vault: FIREWALL_WEAVE_STATIC
      prompt: List of IPs/CIDRs to allow for Weave (specify local networks, not public)
    to:
      vault: FIREWALL_WEAVE_STATIC

services:
  weave:
    image: colinmollenhour/confd-firewall
    secrets:
      - secret: FIREWALL_WEAVE_STATIC
        name: FW_STATIC
        type: env
    environment:
      - FW_MODE=host
      - FW_SERVICE=weave
      - FW_PROTO=tcp,udp
      - FW_PORTS=6783:6784
    cap_add:
      - NET_ADMIN
    network_mode: host
    instances: 1
    deploy:
      strategy: daemon
      min_health: 0.0

This is a simplified example (the full version uses etcd to discover nodes for updating firewall rules dynamically, but the containers won't even start so it shouldn't matter).
I, [2017-11-08T22:28:37.538185 #1]  INFO -- Kontena::Workers::ImagePullWorker: pulling image: colinmollenhour/confd-firewall:latest
I, [2017-11-08T22:28:37.721664 #1]  INFO -- Kontena::Workers::ImagePullWorker: pulled image: colinmollenhour/confd-firewall:latest
W, [2017-11-08T22:32:36.940923 #1]  WARN -- Kontena::Launchers::IpamPlugin: timeout after waiting 301.6s of 300.0s until: IPAM running
W, [2017-11-08T22:33:35.763972 #1]  WARN -- Kontena::Workers::WeaveWorker: timeout after waiting 360.4s of 300.0s until: weave running
E, [2017-11-08T22:33:35.765415 #1] ERROR -- : Actor crashed!
Timeout::Error: Timeout after waiting 300.0s until: weave running
        /app/lib/kontena/helpers/wait_helper.rb:66:in `wait_until!'
        /app/lib/kontena/helpers/weave_helper.rb:59:in `wait_weave_running?'
        /app/lib/kontena/workers/weave_worker.rb:51:in `on_dns_add'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `public_send'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/call/async.rb:7:in `dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:50:in `block in dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'
I, [2017-11-08T22:33:35.774817 #1]  INFO -- Kontena::Workers::WeaveWorker: initialized
W, [2017-11-08T22:34:35.864862 #1]  WARN -- Kontena::ServicePods::Creator: timeout after waiting 358.1s of 300.0s until: network ready
W, [2017-11-08T22:34:35.869376 #1]  WARN -- Kontena::Workers::ServicePodWorker: failed to sync firewall.weave-1 at 2017-11-08 22:28:37 UTC: Timeout after waiting 300.0s until: network ready
W, [2017-11-08T22:34:35.869474 #1]  WARN -- Kontena::Workers::ServicePodWorker: Timeout after waiting 300.0s until: network ready (Timeout::Error)
/app/lib/kontena/helpers/wait_helper.rb:66:in `wait_until!'
/app/lib/kontena/helpers/weave_helper.rb:65:in `wait_network_ready?'
/app/lib/kontena/service_pods/creator.rb:41:in `perform'
/app/lib/kontena/workers/service_pod_worker.rb:120:in `ensure_running'
/app/lib/kontena/workers/service_pod_worker.rb:97:in `ensure_desired_state'
/app/lib/kontena/workers/service_pod_worker.rb:76:in `block in apply'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:97:in `exclusive'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid.rb:421:in `exclusive'
/app/lib/kontena/workers/service_pod_worker.rb:74:in `apply'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `public_send'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `dispatch'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/call/async.rb:7:in `dispatch'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:50:in `block in dispatch'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'
I, [2017-11-08T22:34:35.908165 #1]  INFO -- Kontena::Workers::ServicePodWorker: creating firewall.weave-1
I, [2017-11-08T22:34:35.908322 #1]  INFO -- Kontena::ServicePods::Creator: creating service: firewall.weave-1
I, [2017-11-08T22:35:35.959154 #1]  INFO -- Kontena::NetworkAdapters::Weave: network and ipam ready, ensuring default network with subnet=<IP_ADDRESS>/16 iprange=<IP_ADDRESS>/17
E, [2017-11-08T22:35:43.018658 #1] ERROR -- : Actor crashed!
Kontena::NetworkAdapters::IpamError: 500 "Internal Server Error"
        /app/lib/kontena/network_adapters/ipam_client.rb:117:in `handle_error_response'
        /app/lib/kontena/network_adapters/ipam_client.rb:47:in `rescue in reserve_pool'
        /app/lib/kontena/network_adapters/ipam_client.rb:34:in `reserve_pool'
        /app/lib/kontena/network_adapters/weave.rb:190:in `ensure_default_pool'
        /app/lib/kontena/network_adapters/weave.rb:156:in `on_ipam_start'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `public_send'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/call/async.rb:7:in `dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:50:in `block in dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'
E, [2017-11-08T22:35:43.026216 #1] ERROR -- : Actor crashed!
Celluloid::DeadActorError: attempted to call a dead actor: already_started?
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-essentials-0.20.5/lib/celluloid/internals/responses.rb:29:in `value'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/call/sync.rb:45:in `value'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/proxy/sync.rb:22:in `method_missing'
        /app/lib/kontena/workers/weave_worker.rb:23:in `initialize'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `public_send'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/call/sync.rb:16:in `dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:50:in `block in dispatch'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'
E, [2017-11-08T22:35:43.027220 #1] ERROR -- : Error ( RuntimeError ) at start of supervised instance of Kontena::Workers::WeaveWorker
E, [2017-11-08T22:35:43.027474 #1] ERROR -- : Actor crashed!
RuntimeError: a container instance went missing. This shouldn't be!
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-supervision-0.20.5/lib/celluloid/supervision/container.rb:118:in `restart_actor'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:15:in `block in call'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
        /usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'
W, [2017-11-08T22:35:43.031655 #1]  WARN -- Kontena::Workers::ServicePodWorker: failed to sync firewall.weave-1 at 2017-11-08 22:28:37 UTC: attempted to call a dead actor: network_ready?
 (Celluloid::DeadActorError)
/usr/lib/ruby/gems/2.3.0/gems/celluloid-essentials-0.20.5/lib/celluloid/internals/responses.rb:29:in `value'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/call/sync.rb:45:in `value'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/proxy/sync.rb:22:in `method_missing'
/app/lib/kontena/helpers/weave_helper.rb:66:in `block in wait_network_ready?'
/app/lib/kontena/helpers/wait_helper.rb:33:in `block in wait_until'
/app/lib/kontena/helpers/wait_helper.rb:32:in `loop'
/app/lib/kontena/helpers/wait_helper.rb:32:in `wait_until'
/app/lib/kontena/helpers/wait_helper.rb:63:in `wait_until!'
/app/lib/kontena/helpers/weave_helper.rb:65:in `wait_network_ready?'
/app/lib/kontena/service_pods/creator.rb:41:in `perform'
/app/lib/kontena/workers/service_pod_worker.rb:120:in `ensure_running'
/app/lib/kontena/workers/service_pod_worker.rb:97:in `ensure_desired_state'
/app/lib/kontena/workers/service_pod_worker.rb:76:in `block in apply'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:97:in `exclusive'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid.rb:421:in `exclusive'
/app/lib/kontena/workers/service_pod_worker.rb:74:in `apply'
/app/lib/kontena/workers/service_pod_worker.rb:33:in `update'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `public_send'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `dispatch'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/call/async.rb:7:in `dispatch'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:50:in `block in dispatch'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
/usr/lib/ruby/gems/2.3.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'

The container adds firewall rules via iptables to deny traffic to non-whitelisted IPs. Here is a script that effectively does the same thing, only not dynamic or dockerized:
#!/bin/bash

set -e -x

IF=$(ip route | awk '/^default/{print $5}')

# Cleanup
iptables -D INPUT -i $IF -p tcp -m tcp --dport 6783:6784 -j DOCKER-HOST-kontena || true
iptables -D INPUT -i $IF -p udp -m udp --dport 6783:6784 -j DOCKER-HOST-kontena || true
iptables -F DOCKER-HOST-kontena || true
iptables -X DOCKER-HOST-kontena || true

[[ $1 = "disable" ]] && exit 1

iptables -N DOCKER-HOST-kontena
iptables -A DOCKER-HOST-kontena -s <IP_ADDRESS>/20 -j RETURN
iptables -A DOCKER-HOST-kontena -s <IP_ADDRESS>/20 -j RETURN
iptables -A DOCKER-HOST-kontena -j DROP

iptables -I INPUT -i $IF -p tcp -m tcp --dport 6783:6784 -j DOCKER-HOST-kontena
iptables -I INPUT -i $IF -p udp -m udp --dport 6783:6784 -j DOCKER-HOST-kontena

However, I've tried many times removing the firewall rules, removing the leftover containers (if any) checking that the agents are still healthy (checked agents, etcd, weave for errors like timeouts) and I still can't deploy this stack...
Is this a bug or user error, and how can I get this up an running?

All of those errors point at etcd or weave being unhealthy: the kontena-ipam-plugin can't start if etcd isn't working, and kontena-etcd can't work if the weave overlay network doesn't work. Basic weave troubleshooting is checking ip addr show dev weave on the nodes, and checking connectivity between the nodes with ping 10.81.0.X. Since you're setting up iptables INPUT drop rules, you also need to verify that the etcd service also works: curl http://10.81.0.X:2379/health.
To reset the iptables rules completely, you may want to try rebooting the nodes. If ping 10.81.0.X works and you can deploy services after rebooting, then try re-configuring those iptables rules and see if the ping stops working, or if etcd stops working - I expect it would.
There's several things you need to take into account when setting up iptables INPUT rules, based on the Node Infrastructure Services:

The kontena-etcd connections on <IP_ADDRESS>, 10.81.0.X and the docker0 bridge IP on TCP port 2379/2380
Weave TCP port 6783 + IPSec ESP between the nodes using their public/private IP

In particular, whitelisting UDP port 6783/6784 traffic from the external node addresses is not going to work re IPSec. You need to match the overlay network packets twice in your iptables ruleset: first the IPSec ESP packets with the external node addresses, and then the decapsulated pcakets with the overlay network addresses.

BTW the timing in those logs is odd, normally this would be #2683 but the timing here should be much faster, on the order of <1s, not three minutes:
W, [2017-11-08T22:32:36.940923 #1]  WARN -- Kontena::Launchers::IpamPlugin: timeout after waiting 301.6s of 300.0s until: IPAM running
I, [2017-11-08T22:35:35.959154 #1]  INFO -- Kontena::NetworkAdapters::Weave: network and ipam ready, ensuring default network with subnet=<IP_ADDRESS>/16 iprange=<IP_ADDRESS>/17
E, [2017-11-08T22:35:43.018658 #1] ERROR -- : Actor crashed!

Also:
W, [2017-11-08T22:33:35.763972 #1]  WARN -- Kontena::Workers::WeaveWorker: timeout after waiting 360.4s of 300.0s until: weave running
W, [2017-11-08T22:34:35.864862 #1]  WARN -- Kontena::ServicePods::Creator: timeout after waiting 358.1s of 300.0s until: network ready

Not sure what's going on there to cause the agent to slow down that badly... must be hitting some timeouts because of the -j DROP?

So I did the following steps:

Completely shut down and removed all kontena-agent containers on this grid including weave, ipam, etcd and cadvisor containers then rebooted all nodes and verified that iptables rules are the defaults and all table policies are ACCEPT so nothing is being blocked at all.
Verified hostnames and private IP addresses:

test2.local.lan -> <IP_ADDRESS>
test3.local.lan -> <IP_ADDRESS>
test4.local.lan -> <IP_ADDRESS>

Verified weave adapter is up and noted IPs using ip addr show dev weave.

test2.local.lan -> <IP_ADDRESS>
test3.local.lan -> <IP_ADDRESS>
test4.local.lan -> <IP_ADDRESS>

Checked weave logs for errors and now I see the following:

INFO: 2017/11/09 17:41:06.802756 ->[<IP_ADDRESS>:41783] connection accepted
INFO: 2017/11/09 17:41:06.807222 ->[<IP_ADDRESS>:41783|ea:ba:c8:b5:52:f9(test2.local.lan)]: connection shutting down due to error
: local "ea:ba:c8:b5:52:f9(test2.local.lan)" and remote "ea:ba:c8:b5:52:f9(test4.local.lan)" peer names collision
INFO: 2017/11/09 17:41:06.891905 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2017/11/09 17:41:06.892141 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2017/11/09 17:41:06.895306 ->[<IP_ADDRESS>:6783|ea:ba:c8:b5:52:f9(test2.local.lan)]: connection shutting down due to error:
 local "ea:ba:c8:b5:52:f9(test2.local.lan)" and remote "ea:ba:c8:b5:52:f9(test3.local.lan)" peer names collision
INFO: 2017/11/09 17:41:06.896793 ->[<IP_ADDRESS>:6783|ea:ba:c8:b5:52:f9(test2.local.lan)]: connection shutting down due to error:
 local "ea:ba:c8:b5:52:f9(test2.local.lan)" and remote "ea:ba:c8:b5:52:f9(test4.local.lan)" peer names collision
INFO: 2017/11/09 17:41:07.034099 ->[<IP_ADDRESS>:57308] connection accepted
INFO: 2017/11/09 17:41:07.037021 ->[<IP_ADDRESS>:57308|ea:ba:c8:b5:52:f9(test2.local.lan)]: connection shutting down due to error
: local "ea:ba:c8:b5:52:f9(test2.local.lan)" and remote "ea:ba:c8:b5:52:f9(test3.local.lan)" peer names collision

Checking ifconfig | grep 52:f9 on each node I see:
root@test2:~/kontena-agent# ifconfig | grep 52:f9
weave     Link encap:Ethernet  HWaddr ea:ba:c8:b5:52:f9
root@test3:~/kontena-agent# ifconfig | grep f9
weave     Link encap:Ethernet  HWaddr ea:ba:c8:b5:52:f9
root@test4:~/kontena-agent# ifconfig | grep f9
weave     Link encap:Ethernet  HWaddr ea:ba:c8:b5:52:f9

So the weave interfaces all have the exact same MAC address.. Is that normal? I was using tmux synchronized panes so thought it could be a timing issue so I repeated all of the above steps making sure that the weave interface was removed after reboot and then started each agent waiting in between and they still all got the same MAC address.. How do I fix this?

The firewall rules I am intending to add are only:
-N DOCKER-HOST-kontena
-A DOCKER-HOST-kontena -s <IP_ADDRESS>/20 -j RETURN  # private IPs
-A DOCKER-HOST-kontena -s <IP_ADDRESS>/20 -j RETURN  # public IPs
-A DOCKER-HOST-kontena -j REJECT

-I INPUT -i bond0 -p tcp -m tcp --dport 6783:6784 -j DOCKER-HOST-kontena
-I INPUT -i bond0 -p udp -m udp --dport 6783:6784 -j DOCKER-HOST-kontena

Since the firewall default policies are ACCEPT adding these rules should not break esp packets, correct? Do you see any issues with adding these rules? Also, for better security are there some rules I should add to block unauthorized ESP packets?

Ok so researching further I see that /etc/machine-id is identical on the nodes.. I changed two of these and am trying to get it all working again but it is one issue after another..

On the subject of firewalls, since nodes connect to the master before they connect to each-other, couldn't the agent automatically add firewall rules such that the nodes are only exposed to each-other? That is:

New node connects, master now knows node's public and private IP address.
Master notifies other nodes of new node IP address, agents update firewalls to allow new node.
Once new node is connected, it adds it's own firewall rules to block traffic not coming from the other nodes.

This is basically what I'm trying to accomplish but I'm having to do it outside of the core using additional services and it seems everyone would benefit from this being either the default functionality or supported as an option.

Ok, so I actually seem to have everything working including the firewall rules. I don't know if it is blocking ESP packets so I'd love some guidance on how to handle those with iptables.
Suggestions for features/bug fixes if interested:

I think the upgrade to weave caused the MAC addresses to no longer be unique due to my duplicate machine IDs (thanks, packet.net). Perhaps this could have been detected and warned ahead of time somehow?
Have kontena node ls report if there are cluster problems.. Too many times it has taken me too long to realize there is some sort of issue with etcd/ipam/etc.  In this case I didn't suspect that issue because it was working before but I think it broke due to my recent upgrade or reboot and duplicate machine ids and not the firewall.
Built-in firewall protection would be awesome!
Some new command to give a detailed report on health issues.. looking for and trying to decipher ruby stack traces is not very helpful for people like me that don't know the internals well enough.
Stack deploy command could use the above detailed health report to give errors before trying to deploy. E.g. "Warning: Etcd cluster is unhealthy on node-1. Deploy is likely to fail."

Yes, this looks like an issue where the iptables rules themselves were fine, but weave was unhealthy - I'm guessing that ping 10.81.0.X was not working in this case, even before adding the iptables rules?
I definitely also agree that the error handling/reporting for these kind of situations needs to be improved, there's a wide variety of causes for this kind of breakage, and trying to diagnose the underlying problems from stack deploy errors like Celluloid::DeadActorError: attempted to call a dead actor: network_ready? is hard. Better diagnostics for these kinds of issues is exactly the underlying motivation for the WIP agent refactoring in #2582 and the related Kontena::Observable mechanism in  #2704, but that's stalled because of other work on 1.4.
#2062 is the general issue for the concept of actively monitored "node health", which is a broad topic that covers everything from not having the server schedule instances onto unhealthy nodes to trying to report some kind of more useful errors for stack deploys. I definitely agree that the agent should be aware of things like weave errors, and it should be able to report some kind of human-readable error for diagnostics in that situation.
There is the kontena etcd health command that actively queries each etcd node, and that will also reveal 10.81.0.X connectivity problems. In 1.4 the kontena node health will also show that information. But agreed that users are unlikely to know to run those commands, and turning to kontena node ls for diagnostics currently only really shows the agent websocket connection state. Explicitly querying the health of all nodes synchronously is too slow for kontena node ls, we need the agent to be actively reporting it...

Re the underlying issue with the weave node identity conflicts, there's a history of similar issues on various providers, but that used to be about machines with hardcoded/cloned /sys/class/dmi/id/product_uuid:

https://github.com/weaveworks/weave/issues/2427
https://github.com/kontena/kontena/issues/1541

I think this it first time I've heard of duplicate /etc/machine-id on packet.net nodes? Sounds like something that would be worth reporting...

Thanks for all the great feedback!
I've got the firewall running on production now with no issues, although I still don't fully understand what went wrong on my test cluster. I'm a little worried about what would happen if such an issue happened on production because the only way I got it all working again was to completely remove all docker containers and kontena-related volumes on all nodes and bring them back up one at a time. I think my etcd cluster somehow got corrupted on one of the other grids that didn't have hte duplicate machine-id issue so that wasn't the only problem. Resetting is both slow and error-prone so it would be great if there was some sort of command to "reset" etcd when it blows up.. What is the simplest way to do this? I was doing something like:
$ docker-compose down (removes kontena-agent)
$ docker stop kontena-etcd kontena-ipam-plugin kontena-cadvisor weave
$ docker rm kontena-etcd kontena-ipam-plugin kontena-cadvisor weave
$ docker volume prune
$ docker-compose up -d

Is there a faster or less-destructive way?
The packet.net nodes are over a year old so I assume they've fixed the duplicate machine-id issue by now although I think I'll add resetting the machine-id to my node provisioning script to be safe.
Lastly, would you answer this question, please?

Also, for better security are there some rules I should add to block unauthorized ESP packets?


Update doc strings and comments for confluent-kafka workarounds

See https://github.com/nasa-gcn/gcn-kafka-python/pull/23.

Thanks for keeping this documentation precise and up-to-date.


Potential issue w/Promises in IE11?

I'm submitting a bug report

Aurelia Skeleton Version
skeleton-esnext
skeleton-esnext-aspnetcore
skeleton-esnext-webpack
skeleton-typescript
skeleton-typescript-aspnetcore
skeleton-typescript-webpack

Framework Version:
1.0.0-beta.1.1.4

Please tell us about your environment:

Operating System:
Windows 10

Node Version:
5.12.0

NPM Version:
3.10.5

JSPM OR Webpack AND Version
JSPM 0.16.32

Browser:
IE 11 (Likely lower versions, too.)

Language:
all

Current behavior:
SystemJS's Promise implementation is loaded after Bluebird's. This appears to cause issues when using finally in IE 11 and perhaps other versions.
Expected/desired behavior:

What is the expected behavior?
Bluebird should be loaded after SystemJS to ensure that we are using Bluebird's promise implementation rather than SystemJS's.

What is the motivation / use case for changing the behavior?
(See above.)

SystemJS will polyfill both Promise and URLSearchParams if one of them is missing, so SystemJS will override Promise if URLSearchParams is missing from IE11.

I believe that is what is happening.

Happy to provide a PR if this seems like a legit change.

PRs are welcome. cc @AshleyGrant


Suggestion in the future: Download video with/without danmaku comment?

Maybe download the single xml danmaku comment file, instead of embed the danmaku into the video itself, you can watch it with local danmaku player.


wip: Fix enum serialization in instructions

Previously, these enums were serialized into four bytes - deserialization expects one.
NOTE: Will add tests. Would be surprising if this was actually broken, maybe I'm just missing a setting?
@dafyddd

We sometimes serialize them with 1, sometimes with 4

Hmm. The problem is that currently MangoInstruction::unpack(&my_instr.pack()) may return nonsense. I'd say the pack() is broken, since unpack() is part of the public interface. I'll see if I can fix that without adjusting the enum serialization width globally.

Ah, the layouts that use 4 bytes are for serum_dex::matching::Side, which this patch doesn't touch.

Tests are added. The patch also covers fixing ChangePerpMarketParams::pack() now.

Wow thanks for taking the time to figure out serde custom serialization. I chose to just leave it not working on the rust side.


Accessible variants of checkbox and radio-button

Provide a general summary of the feature here
Currently checkbox and radio button, when switched to variant Valid or Invalid, they only change the color or a marker, which isn't compliant with wcag. We need another visual marker for this.
🤔 Expected Behavior?
Additional icon is present in the checkbox and radio-button component, marking that the answer was correct or incorrect.
😯 Current Behavior
Currently it's only the color of radio or checkbox change;
💁 Possible Solution
Please see the example screen
🔦 Context
This is particuarly important for tests or review of answers. The student need the information about what they selected, but also if that was a good or bad choice.
💻 Examples

🧢 Your Product/Team
TEAS

Perhaps that could be answered in another way. Maybe these components (and probably more to come) could have something like a variant (of correctness) wrapper, that could be surrounding it? Then it would be prepared and consistent with other elements that might need this highlight (like text/ selected image and so on).

@marcin-siekaniec Thanks for filing this issue. At the moment the SLDS does not support your specific usecase. I can see there being a (companion?) library though that "extends" the SLDS components to provide this functionality. But i'm not sure what the "official" position is on that. We will let you know when we do.

Discuss with architects what the plan is with AFC.


VROID import does not have bones

When import VROID character (vrd -> gltf) the bone hierarchy comes as Empty, is there anyway we can import the bones but with weight and everything?
Thanks!

I think this is the same as #38, which is fixed in the latest release. @enzyme69 Can you check?


Merge active branch to master

There's a bunch of changes in here over a long time.   But this is the actively used branch, so I'd like to merge it to master.
It also has my latest change for updating to Chef 13 compatibility:
https://github.com/art19/chef-netuitive/pull/4/commits/6d994ccc5b13a85139f0350af3250891f2c36c82

The branch we normally use is art19-patched: https://github.com/art19/chef-netuitive/compare/art19-patched...art19:drew/AROR-1950
master should reflect upstream master, though it seems like we're out of sync, and should fix that: https://github.com/art19/chef-netuitive/compare/master...Netuitive:master

(and of course, art19-patched should be as close to upstream master as possible, including making a PR to upstream with your change)


[CARBONDATA-4213] Fix update/delete issue in index server

Why is this PR needed?
During update/delete, the segment file in the segment would come as an empty string due to which it was not able to read the segment file.
What changes were proposed in this PR?

Changed the empty string to NULL
Added empty segment file condition while creating  SegmentFileStore.

Does this PR introduce any user interface change?

No
Yes. (please explain the change and update document)

Is any new testcase added?

No
Yes

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbonPRBuilder2.3/5565/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbon_PR_Builder_2.4.5/3822/

retest this please

Build Failed  with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbon_PR_Builder_2.4.5/3823/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbonPRBuilder2.3/5566/

retest this please

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbonPRBuilder2.3/5572/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbon_PR_Builder_2.4.5/3829/

retest this please

Build Success with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbonPRBuilder2.3/5577/

Build Success with Spark 2.4.5, Please check CI http://<IP_ADDRESS>:12602/job/ApacheCarbon_PR_Builder_2.4.5/3834/

retest this please

LGTM

LGTM


add env command

Overview (What and Why)
We should provide an easy way to install the dev environment locally.
It makes sense to move the check command under the env command, and also add something like env install with optional --all or --deps flags to install everything or specify single deps.
All the install commands can be taken from the base-image Docker file.
swanky.config should keep track of the env deps in the new env field, and the command should read from there, or overwrite it if a version is specified when the command is invoked
How

[x] create a new env command
[x] move the check functionality under env
[x] implement an install command to install all or individual deps
[x] add the env section to swanky.config and implement the edit flow

Definition of Done

[ ] above changes merged and released
[ ] docs updated

Open Issues and Blockers

https://github.com/inkdevhub/swanky-cli/pull/190

since #190 is already merged, I will express my approval here, although with one question:
when I try to install just a single dependency, swanky seems to be installing all of them:
../bin/run.js env install -d cargo-dylint
✔ Installing rust OK
✔ Installing cargo-dylint OK
⠋   Installing cargo-contract^

is this because my local versions differ from the default ones? @ipapandinas

thank you for your review @pmikolajczyk41
I've updated the command to make the --all flag implicit and have removed it. If specific dependencies are provided using the --deps flag, only those specified dependencies will be installed


Start Page

Hi there,
with the current project configuration, the Rocket.Chat app starts at the url https://rocket.chat/home, so there is not way to set another host url.
I propose:
My [ ] a local start page

[x] this start page should look if an host url has already been provided and do a redirect
[x] otherwise, it should show an input field for host url
[x] if on start, the internet connection is unavailable and appcache is empty, the app should warn the user (right now, the app shows a blank screen)

Agreed.

I am working on it

In order to enable the start page, un comment var INDEX = 'file://' + path.join( __dirname, 'app.html' ); in app/main.js

Other acceptance criteria:

[ ] validate the form and add ux callback

@engelgabriel what is the best way to identify an host as a Rocket.Chat instance?

I am not sure.. maybe we have to create one.

Probably using the event emitter once loaded, or a custom http header on the initial request

I prefer the header option

@rodrigok can you implement this on the main project and let @edoardocavazza know?
https://github.com/RocketChat/Rocket.Chat/issues/286

@engelgabriel of course

I am thinking that this start page might be useful also for Cordova applications... if you agree, maybe we should move it to a dedicated repository, and use git subprojects in this one.

Definitely... let's get it working first, and see how to do it.

@edoardocavazza I just added the header to all responses

Thank you @rodrigok !!!

When https://rocket.chat is updated to @rodrigok commit and ApplicationCache is enabled, I think we are ready for some tests.

@edoardocavazza, https://rocket.chat was updated to latest commit right now.

Thanks @rodrigok , the start page now properly recognize https://rocket.chat as a valid Rocket.Chat instance :+1:

@edoardocavazza Nice :D

So how does one configure a custom Rocket.Chat instance?

@mitar on the version 0.0.7 there is an option to change/add servers.
They will add icons to the right bar:


Introduced await as a more feature rich version of eventually for whe…

…n you want to use custom polling periods #793

Did you bring these guys straight from Awaitility?

I think that await might not be the best name here.
It is very used in CoRoutines

await is only used in coroutines as part of deferred, not as a standalone function, so it won't clash. I could call it until.

I've renamed it until, added better (not copied) docs, and moved eventually back to the original package.
Please merge if you're happy.


Health check infrastructure

Multiple nodes and many services on them work together. Consequently, it may take a few days before any issue being noticed when one component breaks.
Add a health check mechanism so we can monitor the status of the webserver, the importer (applier), and all testers, and perhaps even the IMAP accounts we use, in a flexible way.
A previous attempt was to use Ansible Tower, together with auto-deploy. Two main problems:

It's not open source.
It doesn't have the git/github trigger for auto-deployment. Only a recurring trigger is supported.

Ideas to use other dev-ops software are also welcome!
Alternatively, we can build this functionality into the server code (mods/healthcheck.py, for example), and rely on https://uptimerobot.com/ to monitor its availability.

@bonzini Any input? :)

Not really an expert and I didn't think much about it, but I would rather not reinvent the wheel. There must be some open source components to do this... What do you mean by auto-deploy?

Auto-deploy is a different story: I want some way to install new code to next.patchew.org whenever we push to github master.
I agree we should better use a library, I know little about this area too and this needs some research. However adding a mods/healthcheck.py is not necessarily reinventing a wheel: even to integrate with something like Prometheus, this may be required work.
What I really mean by "alternative" is we can instead keep this as simple as a few line of code:

Add a URL https://patchew.org/status
Check a few statistics from server logs and database in that URL handler, and compute the health level
Return HTTP 200 or an error depending on the health level
Monitor this URL with https://uptimerobot.com/ so we get email notifications upon error

I think Prometheus or Uptime Robot would be integrated at the Django level? Something like https://github.com/korfuri/django-prometheus or https://github.com/uncommitted-and-forgotten/django-uptimerobot. You might need a plugin to add patchew-specific counters, but in general DB and web server access should be handled outside Patchew.
Would you run the Prometheus (or Uptime Robot) server on the tester and importer too? Perhaps the tester should be moved out of patchew-cli and into a separate script (and the REST API issue also talks about Patchew "pushing" series to testers via webhooks, instead of the other way round).


⚠ ClamAV has degraded performance

In 2b765ea, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 95 ms

Resolved: ClamAV performance has improved in 8443e7d.


python3Packages.socketio-client: init at 0.7.2

Motivation for this change
This socket.io client library is a dependency for ripe-atlas-cousteau (https://github.com/RIPE-NCC/ripe-atlas-cousteau) which is a Python client library for RIPE Atlas API (see #155267 for more context).
Tests cannot be enabled because they will use localhost networking for websockets actual tests.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
tes
[x] Fits CONTRIBUTING.md.

Thank you for the review, you're right, I will perform the changes.
Le lun. 17 janv. 2022 à 09:33, Fabian Affolter @.***> a
écrit :

@.**** commented on this pull request.
Please add pythonImportsCheck.
In pkgs/development/python-modules/socketio-client/default.nix
https://github.com/NixOS/nixpkgs/pull/155269#discussion_r785732317:

+, fetchFromGitHub }:

+buildPythonPackage rec {
⬇ Suggested change
-, fetchFromGitHub }:
-buildPythonPackage rec {
+, fetchFromGitHub
+}:

+buildPythonPackage rec {

In pkgs/development/python-modules/socketio-client/default.nix
https://github.com/NixOS/nixpkgs/pull/155269#discussion_r785732377:

checkInputs = [

coverage

nose

];

Can be removed as the tests are not executed.
⬇ Suggested change

checkInputs = [

coverage

nose

];

In pkgs/development/python-modules/socketio-client/default.nix
https://github.com/NixOS/nixpkgs/pull/155269#discussion_r785732441:

];

checkInputs = [

coverage

nose

];

Perform networking tests.

doCheck = false;

passthru.updateScript = ./update.sh;

meta = with lib; {

description = "A socket.io client library for protocol 1.x";

homepage = "https://github.com/invisibleroads/socketIO-client";

license = licenses.gpl3;

⬇ Suggested change

license = licenses.gpl3;

license = licenses.mit;

see https://github.com/invisibleroads/socketIO-client/blob/master/LICENSE
In pkgs/development/python-modules/socketio-client/default.nix
https://github.com/NixOS/nixpkgs/pull/155269#discussion_r785733560:

propagatedBuildInputs = [

six

websocket-client

requests

];

checkInputs = [

coverage

nose

];

Perform networking tests.

doCheck = false;

passthru.updateScript = ./update.sh;

Please remove this. Doesn't add value as the module is not updated on a
regular base (last action in the repo was over 4 years ago) and Python
modules are updated in bulk.
—
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/155269#pullrequestreview-854014083,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACMZRC52LSV2O6UEZADDPDUWPH3ZANCNFSM5MDI4OPQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Everything has been addressed, cc @fabaff @SuperSandro2000

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 155269 run on x86_64-linux 1

2 packages built:

python310Packages.socketio-client
python39Packages.socketio-client