fixes #492

see #492

@ennersk hi, thanks so much for this PR! Could you perhaps clarify what you meant by https://github.com/http-rs/tide/issues/205#issuecomment-626737560:

I think it is perfect as it is currently and vote for closing this one.

Are you in favor of this PR, or do you think we should keep things as-is? thanks heaps!

ouch, things are moving fast here :) after running into several conflicts after rebasing I think its better to close this one and submit my little change anew

@ennersk hi, thanks so much for this PR! Could you perhaps clarify what you meant by #205 (comment):

I think it is perfect as it is currently and vote for closing this one.

Are you in favor of this PR, or do you think we should keep things as-is? thanks heaps!

Well, in the other ticket it was also about funny trailing slashes, so I linked them.
What I meant in the other issue is that in http the paths "/foo/bar" and with trailing/ "/foo/bar/" identify 2 different resources. Currently tide complies to this - what I like -
However I understand many developers (like the one opening the ticket) favoring to treat them the same, as it is confusing, but I think tide should keep being compliant, so I voted for just closing #205.
Maybe printing out all registered routes on start would be helpful, one would immediately spot two routes, one with and one without a trailing slash - and could fix it if it was unintentional. But this would be another issue...


Add shared object version in Signed Effect Transaction

If we don't do it we aren't able to sync and the client cannot really make sense of the execution result.

More context for this issue:

The exact shared object version and digest is not know to the creator of the transaction unlike the owned or immutable objects, at the time of the transaction creation.
Instead the object version is determined once the certificate is sequenced by consensus and assigned by validators, and is known (a prerequisite) at the time the ceritficate can be processed.
At that time we need to take the shared object referenced used as inputs, and add them to the effects certificate, to allow anyone with an effects certificate to fully reproduce the execution of the transaction.
That should include the the sequence of shared object IDs, their version and the digest at that version.

One challenge that I foresee in the Gateway is, even with the effects, to be able to re-execute it we also need the input objects. For shared objects, it's unclear to me where to get the objects.


Get the various translations on the UI

My awesome drawing is self-explanatory

Magnificent.
@z4rd Vincent is our new Creative Director. You can stop doing DevOps Vincent.


WIP: Disabling a number of tests to improve CI stability.

Description
This PR disables some tests that have been flaky (failing non-deterministically in CI).  This includes disabling windows based GPU tests, as we've had many recent CUDA launch failures during tests runs with these hosts.
Disabled tests:

Windows based GPU tests.
test_gluon.test_hybrid_static_memory_switching (MKL only). due to #11171

Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

shall we address this in #11440?

We're using different approaches and thus would like to keep it separate


Broken time ruler view

Describe the bug
Unlike the views shown on GitHub README with the date timeline displayed horizontally, my view displays the date vertically, buttons do not align, and there is no time ruler.
To Reproduce
Steps to reproduce the behavior:

Create a new Obsidian vault
Install Dataview and Time Ruler plugins

Expected behavior
The views shown on GitHub README with the date timeline displayed horizontally and the time ruler shown vertically.
Screenshots
How the view should look

How my view looks

Obsidian Version:

[ ] Mac Desktop

Additional context
This is tested on a new obsidian vault, no theme, no other plugins other than Dataview and Time Ruler.

That's very strange. Let me try to reproduce the issue.

I just tried on a vault with only those two plugins installed and it looks correct. In order to fix this can you send me the test vault in question? Upload it as a .zip. Thanks!

test-task-vault.zip
Hi Joshua!
Thank you for looking into this. I really want to try out your plugin.

Ok, it's just an oversight where styles.css isn't included. Let me update the release.


zfs style syntax

I changed the syntax to match the zfs style. (0.7.7 Goals: Change syntax of ZFS commands to match ZFS syntax.)
I also changed the way of getting the dataset location and mountpoint to match the style in 'ioh-guest' to make it not depend on hardcoded mountpoints and fixed pools. (Preparing for 0.7.9 Goals: Allow iohyve datasets to live wherever the user wants them)
Breaking changes:

iohyve getall <guestname> no longer exist and is replaced by iohyve get all [guestname] (Note: guestname is now optional. If not given all properties of all guests are printed.)
iohyve get <name> <prop> is now iohyve get <prop> <name>
iohyve set <name> <property=value> ... is now iohyve set <property=value> ... <name>

Because it is a bigger change, it would be nice if you could test it and look for bugs.

I'll dig around and take a look. Great work so far!

That iteration function looks good to me.
General ports and shell wizard Lars had used that method in his massive PR.

No movement or discussion in three weeks, closing PR. I'll be adding changes made in #170 soon, causing even more conflicts.


Statement function strtodate

Fixes #3716.
DMLStatement and DQLStatement doesn't support STR_TO_DATE function. InsertStatement couldn't parse parameter of STR_TO_DATE function correctly.
Changes proposed in this pull request:

Support STR_TO_DATE function in DMLStatement and DQLStatement.
Modify method getLiteralSQL of SQLCasesLoader to support SQL which includes '%' character.

Pull Request Test Coverage Report for Build 1128

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 68.079%

Totals

Change from base Build 603:
0.002%

Covered Lines:
11389

Relevant Lines:
16729

💛  - Coveralls


Accounting Schema

Would anyone have an idea of what the accounting backend/tables look like? Would they be using accrual based accounting or cash accounting?

We use Apache Camel (and the isisaddons' publishmq module) to call the SOAP endpoints of a general ledger application.  I'm afraid after that it's a black box to me.  I don't think there are any assumptions within Estatio as to how you do the accounting, though.
If you do a retro-run of invoices, it will create delta InvoiceItems if there was a change in circumstance for the tenant to be accounted for.  Any previously invoiced Invoice/InvoiceItems are immutable; a new retrospective Invoice is created to contain such deltas.
HTH
Dan


onBeforeAction isn't being stacked on .extend

https://gist.github.com/Firfi/3c0950b57497bdc2a96e
error is Error: Handler with name 'onBeforeAction' already exists., it appears only when I visit the route

It seems to be an issue with es6. I just moved router.js to babel and es6.js extension. Maybe it handles .extends somehow differently (I still used the same function() syntax and no arrow syntax).

Link to https://github.com/grigio/meteor-babel/issues/21

can you try to edit your .meteor/packages and put grigio:babel before all the packages?


idsrv.session cookie : secure security control attribute in the set-cookie header

hello,
Tried to browse through documentation and got nowhere...
I've currently a pentest report were am asked to present on my idsrv reponse a set-cookie header passing "secure" as true for the idsrv.session cookie.
but... have been unable to find how to do so? is this only achieved through configuration out of the code somewhere?
my dev env:
asp.net core 2.2 (asp.net identity)
IdentityServer4
F#
been able to set cookie options easily for the asp.net core identity cookie, so was expecting, probably wrongly, to find something similar for this cookie ..?!
 builder.Services.Configure<CookieAuthenticationOptions>(IdentityConstants.ApplicationScheme,fun (cookie:CookieAuthenticationOptions) ->
                                                                        cookie.Cookie.SameSite <- Microsoft.AspNetCore.Http.SameSiteMode.None
                                                                        cookie.Cookie.HttpOnly <- true
                                                                        cookie.Cookie.SecurePolicy <- Microsoft.AspNetCore.Http.CookieSecurePolicy.Always

That cookie is issued as secure if the request is over https.


[Vue] The idea of making RenderController are reactive

Q
A

Bug fix?
no

New feature?
yes

Issues
Fix #...

License
MIT

The idea is to create a bridge between the reactivity of Stimulus values and the reactivity of Vue.js properties.
This would allow to influence the properties of a Vue.js component from the outside without implementing an additional Stimulus controller for this.
Changes to the properties passed to the Vue.js component inside the component would also reflect their change in the Stimulus values.
I have already implemented something similar in some projects. It would be very convenient if this worked out of the box and was useful to someone else.

Added some tests to make sure it really works.
Fixed the non-working mechanism.


await one, two, three instead of await* [one, the, three]

What about
await promise1, promise2, promise3

// or, formatted like like a multi-line single-var statement:

await promise1,
  promise2,
  promise3

?
Compare to the previously proposed sugar for Promise.all:
await* [promise1, promise2, promise3]

// or

await* [ promise1,
  promise2,
  promise3
]

There is no sugar for Promise.all anymore. Just use await Promise.all

The , comma is the lowest on the precedence list, meaning everything else binds first before it. Your suggestion would require await to bind less precedently than ,, and I'm pretty sure that's not a good idea.
For example, someone could equally want:
var results = [await promise1, value2, promise3];

Your change would make this ambiguous... should it await all values in a comma list after it, or just the one?

It could possibly be treat like let or var. For example, we can't write
let results = [var promise1, value2, promise3];

but we can write
var promise1, value2, promise3

just for posterity sake: the problem with await * [ promise1, promise2, promise3 ] (or just await [ promise1, promise2, promise3 ]) was that we'd be arbitrarily favoring Promise.all( [ .. ] ) desugaring instead of Promise.race( [ .. ] ). Invariably, some would have wanted the former and some the latter.
I can't see any argument that makes one more appropriate than the other, so I don't think syntax would have been justified. Ultimately, that same dooming reasoning sinks this OP as well.


[BUG] NumericUpDown temperature control sticks on a single click

Describe the bug
The NumericUpDown temperature control sticks on a single click, rapidly incrementing values.
To Reproduce
Steps to reproduce the behavior:

Go to 'ChatOpenAi node Temperature Setting.'
Click on NumericUpDown control once, up arrow or down arrow.
Notice that it may rapidly increase or decrease values more than one means to.
See error

Expected behavior
Increment value by a single unit.
Screenshots
https://drive.google.com/file/d/1CAn4UBaVkfDyTqstE70yu9mBggVrRcXy/view?usp=sharing
Flow
If applicable, add exported flow in order to help replicating the problem.
Setup

Installation  docker
Flowise Version1.2.13
OS:  Windows 10
Browser chrome, edge

Additional context
Add any other context about the problem here.

PR for the fix was merged - https://github.com/FlowiseAI/Flowise/pull/406, will be pushed to new release in a few days

should be fixed in v1.2.14


Cet-4385 backstage initiative page ladder driven UI

Change description

Description here

Revamp of Initiative page for both ladder- and score-driven.

Overall the code looks very clean!
I did not functionally test locally
I recognize that some of the code changes might be moved code and I may have made some nits on existing moved code -- feel free to dismiss those if they're annoying to update
It's a very big PR so I'm sure I missed things regardless

Are there are any specific areas you'd like me to focus code review and/or anything you'd like help functionally testing?

@FoodProduct Thanks for reviewing this PR! I'll try to fix all the spotted nits, regardless if given code is new or just moved ;). Actually, I can't think about any "hot" areas which should be tested more intensively. And when it comes to the testing - we already tested it together with Cristina, but if you'll find some time to create one or two scorecards with some initiatives/rules exemptions etc and play around it in backstage, it would be great!


feat: :sparkles: Added ability to specify timezone

@joelwalden coming back to changes requested in the json schema, as you can see I've added it as an extra anyOf.
What this means is that properties for both eventbus and eventbridge scheduler stay exclusive. This is much better since the user can only use roleArn, timezone, etc when method: scheduler is specified. I can explain more over a call if you want.


Add support for @model for LLM models

Context
For the agent integration with MoFa, we've added a @name selector capability within the chat input prompt that allows the user to select different agents. See https://github.com/moxin-org/moly/pull/279.

We now want to include this behaviour for LLM models within a chat.
Requirements

Writing @ should bring up a list of models to select from (it should match the items and status of the model selector at the top of the chat panel.
The user should be able to navigate the list via keyboard and select a model.
Once the model is selected the UI should show the selection above the message input (see screenshot above).
Sending a message with the newly selected model will load the model first and then send the message. Once the message is sent the text input should be reset to its initial state.
The user should not be able to select the already current model, that item in the list should be shown as already selected.

We should actually wait to work on this once https://github.com/moxin-org/moly/pull/279 is merged.
I just realized the feature is in the same input prompt, let's avoid more conflicts and add @model support to the already existing feature in that branch.


[DNM] Reproduce ovn scaleup with tls

Depends-On: https://github.com/openstack-k8s-operators/openstack-operator/pull/793
Related-Issue: OSPRH-6899

recheck registry back

recheck depends-on

just for test


MacOS High Sierra: Build error - "#include nested too deeply"

I had zero problems installing kafka-node in this environment, up until now. Now I'm getting a build error upon installing.
Environment

Node version: 9.4.0
Kafka-node version: 2.4.1
MacOS High Sierra
Xcode 9.2

Output:

npm install kafka-node --save

><EMAIL_ADDRESS>install /Users/myname/Documents/Projects/Company/Project/projects/my-library-name/node_modules/snappy
> node-gyp rebuild

  CXX(target) Release/obj.target/snappy/deps/snappy/snappy-1.1.4/snappy-sinksource.o
  CXX(target) Release/obj.target/snappy/deps/snappy/snappy-1.1.4/snappy-stubs-internal.o
In file included from ../deps/snappy/snappy-1.1.4/snappy-stubs-internal.cc:29:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:629:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/typeinfo:61:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:82:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstdlib:86:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdlib.h:94:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/stdlib.h:65:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/wait.h:110:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:72:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
In file included from /usr/local/include/stdint.h:59:
/usr/local/include/stdint.h:2:10: error: #include nested too deeply
#include <stddef.h>
         ^
/usr/local/include/stdint.h:59:11: error: #include nested too deeply
# include <stdint.h>
          ^
/usr/local/include/stdint.h:72:11: error: #include nested too deeply
# include <sys/types.h>
          ^
/usr/local/include/stdint.h:76:10: error: #include nested too deeply
#include <limits.h>
         ^
/usr/local/include/stdint.h:82:11: error: #include nested too deeply
# include <inttypes.h>
          ^
In file included from ../deps/snappy/snappy-1.1.4/snappy-stubs-internal.cc:29:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:629:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/typeinfo:61:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:82:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstdlib:86:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdlib.h:94:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/stdlib.h:65:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/wait.h:110:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:197:2: error: unknown type name 'uint64_t'
        uint64_t ri_user_time;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:198:2: error: unknown type name 'uint64_t'
        uint64_t ri_system_time;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:199:2: error: unknown type name 'uint64_t'
        uint64_t ri_pkg_idle_wkups;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:200:2: error: unknown type name 'uint64_t'
        uint64_t ri_interrupt_wkups;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:201:2: error: unknown type name 'uint64_t'
        uint64_t ri_pageins;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:202:2: error: unknown type name 'uint64_t'
        uint64_t ri_wired_size;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:203:2: error: unknown type name 'uint64_t'
        uint64_t ri_resident_size;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:204:2: error: unknown type name 'uint64_t'
        uint64_t ri_phys_footprint;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:205:2: error: unknown type name 'uint64_t'
        uint64_t ri_proc_start_abstime;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:206:2: error: unknown type name 'uint64_t'
        uint64_t ri_proc_exit_abstime;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:211:2: error: unknown type name 'uint64_t'
        uint64_t ri_user_time;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:212:2: error: unknown type name 'uint64_t'
        uint64_t ri_system_time;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:213:2: error: unknown type name 'uint64_t'
        uint64_t ri_pkg_idle_wkups;
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/resource.h:214:2: error: unknown type name 'uint64_t'
        uint64_t ri_interrupt_wkups;
        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make: *** [Release/obj.target/snappy/deps/snappy/snappy-1.1.4/snappy-stubs-internal.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack     at ChildProcess.emit (events.js:160:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:12)
gyp ERR! System Darwin 17.4.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/myname/Documents/Projects/Company/Project/projects/my-library-name/node_modules/snappy
gyp ERR! node -v v9.4.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm WARN<EMAIL_ADDRESS>No repository field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/snappy):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1

Try to install XCode and these should go away.

See OP - Xcode 9.2 is installed. I also tried completely uninstalling and re-installing it. Nothing changed.

This worked for me using node v9.7.0 and High Sierra 10.13.3. 🤷🏻♂

I had the same error in a different project. Problem was some header files in /usr/local/include that shouldn't be there. Easiest to fix is to run brew doctor and follow instructions.

Thanks @gcamp!
I was deep down this rabbit hole trying to install a python package and after a many hours, yours was the solution that finally worked.

Unfortunately, “brew doctor” didn’t fix this for me.
On Thu, May 24, 2018 at 8:28 AM Ariel Allon<EMAIL_ADDRESS>wrote:

Thanks @gcamp https://github.com/gcamp!
I was deep down this rabbit hole https://xkcd.com/1987/ trying to
install a python package and after a many hours, yours was the solution
that finally worked.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SOHU-Co/kafka-node/issues/881#issuecomment-391735282,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG5JGmdp8fsznCmKpdjEo95kV1iesheGks5t1sN_gaJpZM4SXlTa
.

@vgjenks Look at /usr/local/include/stdint.h and see if it's normal for it to be there. Or just rename it temporarily see if that fixes your problem.

 Thanks so much! Is there a potential
downside to leaving this file renamed and out of service? I don't use XCode
for anything, at all, beyond the requirement to build various libraries
using node-gyp. Thanks again! And again!
On Fri, Jun 1, 2018 at 8:44 AM, Guillaume Campagna<EMAIL_ADDRESS>
wrote:

@vgjenks https://github.com/vgjenks Look at /usr/local/include/stdint.h
and see if it's normal for it to be there. Or just rename it temporarily
see if that fixes your problem.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SOHU-Co/kafka-node/issues/881#issuecomment-393902756,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG5JGgoiWd7VTQ9oyYd314XQZCf7ThhCks5t4VNUgaJpZM4SXlTa
.

This worked for me.
mkdir /tmp/includes brew doctor 2>&1 | grep "/usr/local/include" | awk '{$1=$1;print}' | xargs -I _ mv _ /tmp/includes

@howcrazy It works! Thank you. I have the same problem after migrating everything to a new iMac. (This issue shall be closing.)

@howcrazy I had the same issue when restoring a Time Machine Backup... thanks!

@howcrazy Thank you! It worked for me.

Anybody know what installed the faulty stdint.h, so that a proper upstream report can be filed? We saw a report about this in another project...

Based on https://github.com/commercialhaskell/stack/issues/4186#issuecomment-414379705, the offending header seems to come from a mangled install of libunistring. The library itself looks fine - that file seems generated from lib/stdint.mini.h, and takes effort to not include itself, but it belongs in /usr/local/include/unistring/stdint.h and not in /usr/local/include/stdint.h. I suppose that's due to whatever's installing that library on your systems.
Hope this helps whoever next investigates this bug.

I can confirm what Blaisorblade said, I installed wget from brew which installed libunistring which installed the offending header. Nothing to do with kafka-node btw, just with building anything in general.

@vgjenks查看/usr/local/include/stdint.h，看看它是否正常。或者只是暂时重命名，看看是否能解决您的问题。
I tried a lot of programs, reinstalled a lot of packages, still did not solve this problem, I renamed this file as you said, solved the problem! Thank you!

It looks to me like the fully-correct fix is to:

brew unlink libunistring
brew uninstall libunistring
Make sure /usr/local/include/stdint.h is gone, and delete it if necessary (I think it is)
brew install libunistring

The current version of libunistring appears to not have this problem, but if you've installed an earlier version, the damage has been done, and your build environment poisoned.
I had renamed it to the proper location earlier, and reinstalling found it as a conflict, which I handled with 'brew link --override libunistring'. This serves to confirm the original diagnosis, as relayed by @Blaisorblade
I had been hitting this for a while, and assumed it was stale node libraries. This is so insidious, I might suggest that brew actually check for this and point the user at repair instructions. It's not brew's fault, of course, but it might save a lot of people grief.

@howcrazy solution is genius.
This problem was bitting me for ages.
Thank you all.


i18n Team Loadout UI

Most of the UI that needs translation tagging are marked with TODO: Translation in code.

I'd like to work on this issue

I'd like to work on this task too.
https://discord.com/channels/785153694478893126/824107168936361984/1283479361223131176


File not found

[*] Compiling...
[!] File not found! There's a problem with compiling. build/Windows/chaos.exe/chaos.exe.go:16:2: cannot find package "github.com/kbinani/screenshot" in any of:
/usr/lib/go-1.11/src/github.com/kbinani/screenshot (from $GOROOT)
/root/go/src/github.com/kbinani/screenshot (from $GOPATH)
build/Windows/chaos.exe/chaos.exe.go:17:2: cannot find package "github.com/matishsiao/goInfo" in any of:
/usr/lib/go-1.11/src/github.com/matishsiao/goInfo (from $GOROOT)
/root/go/src/github.com/matishsiao/goInfo (from $GOPATH)
I followed the install instructions and this is the error i get when trying to compile a windows executable. Any help would be appreciated, Thanks.

Some dependencies are not installed, then it can't compile and generate the executable.
You need go-dep package installed on your OS. sudo apt install go-dep.
Run dep ensure to get the dependencies.
All the process are described in https://github.com/tiagorlampert/CHAOS#how-to-install.

Hello, could you try again with the latest version of CHAOS?
I'm closing this old issue.
If the problem persist, please open a new issue.


[Logging V2]  Logs should include data about their source

Currently some of the logs rancher collects do not have any meta data on them regarding service, container, file.  Without this data it is not possible to filter these logs in a meaningful way.
e.g. of an log that cannot be filtered
{
  "_index": "k8s-components",
  "_type": "_doc",
  "_id": "QPnx_nQBv93224yCqqCu",
  "_version": 1,
  "_score": null,
  "_source": {
    "log": "I1006 17:24:07.743856   14521 setters.go:77] Using node IP: \"<IP_ADDRESS>\"\n",
    "stream": "stderr",
    "time": "2020-10-06T17:24:07.744186749Z",
    "foo": "bar"
  },
  "fields": {
    "time": [
      "2020-10-06T17:24:07.744Z"
    ]
  },
  "highlight": {
    "log": [
      "I1006 17:24:07.743856   14521 @kibana-highlighted-field@setters.go@/kibana-highlighted-field@:77] Using node IP: \"<IP_ADDRESS>\""
    ]
  },
  "sort": [
<PHONE_NUMBER>744
  ]
}

Blocked by #29620

Rancher version master-head (10/21/2020)  I've validated that the latest chart version is collecting the node logs properly from the RKE node logs. /var/lib/rancher/logging/rke
I saw the expected output format in the Elastic Search output.

I will validate this in 2.5-head too.

Rancher version v2.5-head (10/21/2020) 61a8a36
I've validated that the latest chart version is collecting the node logs properly from the RKE node logs. /var/lib/rancher/logging/rke
I saw the expected output format in the Elastic Search output.

Rancher version v2.5-head (10/21/2020) 61a8a36
I've validated that the latest chart version is collecting the node logs properly from the RKE node logs. /var/lib/rancher/logging/rke
I saw the expected output format in the Elastic Search output.

Hi izaac,
I don't see logs coming from /var/lib/rancher/logging/rke but rather /var/lib/rancher/rke/log/* in latest rancher, and rancher logging charts.
There's quite no reference anywhere to /var/lib/rancher/logging/rke while this file is growing and can be the cause of Disk Pressure.
Is a ClusterFlow / ClusterOutput supposed to process this file ?


Notifications not received when rebuilt app in closed state

Expected Behaviour
Notification should appear in Android tray when app is closed
Actual Behaviour
Works for a test app (background and closed) built in Ionic/Cordova but when changing the widget id and name only (sender id stays the same) and releasing to production app they only appear when app is in the background not closed
(This may well not be related to the plugin but any advice would be much appreciated!)
Reproduce Scenario (including but not limited to)
Release to test app, change just the id and name and release prod app - test notifications
Notifications received in test app when closed or in background
Notification received in prod app only when in background
Steps to Reproduce
As above
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Android 8.0.0
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
OnePlus A3003
Cordova CLI version and cordova platform version
cordova --version                                    7.1.0
cordova platform version android           6.3.0

Plugin version
cordova plugin version | grep phonegap-plugin-push   1.11.1

Sample Push Data Payload
{
"notification": {
"title": "Test Notification",
"body": "body"},
"to":"regid"
}
Sample Code that illustrates the problem
No code changes involved between working test app and prod app
Only on('registration') implemented as only this is required for the app
Logs taken while reproducing problem
Are there Android logs I should be looking at that don't know about or haven't stumbled across during my week of trying to resolve?

@acahinton version 1.x of this plugin does not support Android 8. You need to upgrade to v2.x

thanks @macdonst - will go the upgrade route...


Remove version: ChilliBits.Spice version 0.14.2

This version is older than what has been set in max-versions-to-keep by the publisher.
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/spicelang/spice/releases/download/0.14.2/spice_x64_setup.msi
Status Code: 200
(Automated message - build 857)


FR: Tag trigger

Would it be possible to add a trigger when a tag is added to a file?

May I ask what would you do with the tag? If it is related to moving file to specific folder, you can use auto file mover rather than waiting implementation in automation :)


memory leak

when I finish the activity,my application will stagnate for a period of time,afterwards the leak canary warn  a  message about memory leaked.I make sure that it caused by android-player.Can you help me?
details when I open it:
`In com.gongxun.centerdata:1.0.4:8.

com.gongxun.centerdata.ui.MainUI has leaked:

GC ROOT android.view.Choreographer$FrameDisplayEventReceiver.mMessageQueue

references android.os.MessageQueue.mMessages

references android.os.Message.next

references android.os.Message.callback

references com.eftimoff.androidplayer.Player$3.this$0 (anonymous class implements java.lang.Runnable)

references com.eftimoff.androidplayer.Player.list

references java.util.ArrayList.array

references array java.lang.Object[].[0]

references java.util.ArrayList.array

references array java.lang.Object[].[0]

references com.eftimoff.androidplayer.actions.property.PropertyAction.view

references android.support.v7.widget.AppCompatImageView.mContext

leaks com.gongxun.centerdata.ui.MainUI instance

Reference Key: 7ff2f583-b6a4-4e73-bd8e-a5c03ad85f95

Device: Xiaomi Xiaomi Mi-4c libra

Android Version: 5.1.1 API: 22

Durations: watch=5025ms, gc=186ms, heap dump=1727ms, analysis=7506ms`

oh,sorry,It's my negligence!
It will have a heavy repeat,if I won't set the count of the animation looping.

@thefirstcoder
Do you have this problem still?
I am investigating some memory leaks in another ticket so they could be indeed be a problem about it.
Thanks for reporting.


kfctl kustomize secretGenerator is broken

Hi y'all. I was deploying master of the kubeflow/manifests and the metadata server wasn't coming up. The pod was stuck in a pending state trying to mount a secret that was not on the system. In the metadata/overlays/db/kustomization.yaml file that secret should be generated by kustomize.
I ran kustomize build ... | kubectl apply -f - and that worked... After pawing through the source code a bit, I learned that kfctl does some merging of it's own beyond rending the overlays with kustomize. The README.md in the manifests repo also talks about this.
I added a test case for it, and to be expected it failed. After looking through the file I finally found the error. The key value is secretGenerator not secretGeneratorMap. After changing that the test passed! Leaving this issue here as a warning to anyone else who tries to deploy the master manifests until my PR is merged.
*You can make the changes I made and compile the binary yourself if you don't want to wait.

This is amazing thank you.
/assign @zhenghuiwang
/assign @gabrielwen

@WillBeebe Thanks for filing this issue.
What kfctl binary do you use?
I think the issue you found was fixed by #187 but kfctl RC2 doesn't contain that fix. Your PR seems only renames a constant but doesn't change any logic. Am I missing something?

@zhenghuiwang I was using the latest release from github 1.0.2 at the time. I also compiled a binary from source and tried it and the error is the same. The root cause is the key that is being saved to the kustomizationMaps => kustomizationMaps[secretsMapGeneratorMap] is the wrong key and not a kustomize key, changing that to secretsGeneratorMap fixes the issue. I haven't compiled and tested #187 but it's possible that change fixes this. I'll put down master now, add my test case and give it a shot.

Confirming that #187 does fix this behavior. I trimmed my PR down to just adding the test case

I should also mention, that when I was compiling from source I didn't have #187 locally. Before 187 my fix was needed, and now it's not. :)


In example Double click on modify features can lead to Uncaught TypeError

In the latest (v4.6.4) modify features example (https://openlayers.org/en/latest/examples/modify-features.html) if I select a country, move a vertex, and then double click on it I quite often get an Uncaught TypeError. I don't know how to get ol-debug for the example but the stack trace I see starts ol.js:369 Uncaught TypeError: Cannot read property 'fa' of undefined. I attach a screen shot of an example. I use Chrome but get the same thing in Edge.
The resulting behaviour seems to be that the map has a point where I double clicked, and a vertex point has followed my mouse, and the map is panning with the mouse and cannot be stopped from panning.
I noticed this in my own code first, and thought it strange, so I came to the example to see what ought to happen.
There is no need to address my own code here, but (using v4.0.0/ol-debug.js) the stack trace I get when I do something similar is
ol-debug.js:27898 Uncaught TypeError: Cannot read property 'minX' of undefined
at ol.structs.RBush.update (ol-debug.js:27898)
at ol.interaction.Modify.handleUpEvent_ (ol-debug.js:65025)
at ol.interaction.Modify.ol.interaction.Pointer.handleEvent (ol-debug.js:18306)
at ol.interaction.Modify.handleEvent (ol-debug.js:65071)
at ol.Map.handleMapBrowserEvent (ol-debug.js:31487)
at ol.MapBrowserEventHandler.boundListener (ol-debug.js:6671)
at ol.MapBrowserEventHandler.ol.events.EventTarget.dispatchEvent (ol-debug.js:7091)
at ol.MapBrowserEventHandler.handlePointerUp_ (ol-debug.js:12358)
at ol.pointer.PointerEventHandler.boundListener (ol-debug.js:6671)
at ol.pointer.PointerEventHandler.ol.events.EventTarget.dispatchEvent (ol-debug.js:7091)
I have seen various issues raised around double clicking (eg #6310) but none with the actual OL example.

I have noticed the same problem (same stacktrace). But have a slightly different way to get the error to show. (Maybe it is the same, but the above just seems to be this problem)
If using modify on selected features i.e.:
https://openlayers.org/en/latest/examples/modify-test.html

Select a line.
double click, but do not release on the second click.
Now while keeping the mouse button pressed drag and edit the line.
Release the mouse. This gives for me the above error every time.

This TypeError appears to be triggered by a call to RBush.prototype.update (where 'item' is undefined) from the modify handleUpEvent function, line 1158: this.rBush_.update(boundingExtent(segmentData.segment), segmentData);.

Hi,
The last example seems not working with this anymore, but this one does;
https://openlayers.org/en/latest/examples/modify-features.html
Follow the same steps as I wrote before and the error will come every time.
I also modified the code and tested select.setActive(false) when starting to modify. This do not work either. I think the problem is that the event 'modifystart' happens first when starting to drag the feature, and not when mouse is down.
https://stackblitz.com/edit/typescript-fa1fg8?file=index.ts
In my own application if testing at lines, and deactivating select, I was able to do the workaround once per line though. The 'modifystart' event was fired every mouse down time. But only once, after the first time a feature was modified the event fired only when dragging again, I have some more logic then only the basic ol one though, but do not think this should have any effect on this behavior.
This issue makes the production app crash frequently, so I would really appriciate if it could be checked at. And it seems that this issue exists for all select and modify applications.

Fixed with #9036.

Is there any fix or workaround for ol4 as well?


Where can I find whether the patient was on ventilation an at any particular time stamp?

This is non-trivial and we welcome collaborative effort on this task!

Will I find this information in nursecharting table?

There is some information relevant to ventilation times in nursecharting, as well as other tables like respiratorycharting. We are working on an approach and will post an update in this repository when we have made more progress.

There are "ventilator" and "nasal cannula" as oxygen administration devices. Can we safely assume that “ventilator” means that someone was intubated?

I think that is a generally safe assumption, but for a few patients this
may refer to non-invasive ventilation via tight-fitting mask and
positive inspiratory pressure.
Roger
On 8/14/2018 3:30 AM, mornin wrote:

There are "ventilator" and "nasal cannula" as oxygen administration
devices. Can we safely assume that “ventilator” means that someone was
intubated?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MIT-LCP/eicu-code/issues/21#issuecomment-412780717,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHDnSkOP_n_KbwXouXf59FkMoOlrzAS3ks5uQnyTgaJpZM4Q9q5W.

--
Roger G. Mark, M.D., Ph.D.
Professor of Health Sciences and Technology
and of Electrical Engineering
Room E25-505
MIT
Cambridge, MA 02139
Tel<PHONE_NUMBER>
Fax<PHONE_NUMBER>

Maybe this helps: using the code from @alistairewj's sofarespi query I'm trying to use this chunk of the code to find whether the patient was on ventilation the first 24 hours of admission:
--this query gets the data from respiratorycare (either invasive airway), respiratorycharting and treatment (either ETT/NiV) to tell whether a patient was mechanically ventilated during the first 24 hours of ICU admission WITH t1 AS   (SELECT DISTINCT patientunitstayid,                    max(CASE                            WHEN airwaytype IN ('Oral ETT', 'Nasal ETT', 'Tracheostomy') THEN 1                            ELSE NULL                        END) AS airway -- either invasive airway or NULL    FROM eicu_crd_v2.respiratorycarea    WHERE respcarestatusoffset BETWEEN -1440 AND 1440    GROUP BY patientunitstayid),      t2 AS   (SELECT DISTINCT patientunitstayid,                    1 AS ventilator    FROM eicu_crd_v2.respiratorycharting rc    WHERE respchartvalue ILIKE '%ventilator%'      OR respchartvalue ILIKE'%vent%'      OR respchartvalue ILIKE '%bipap%'      OR respchartvalue ILIKE '%840%'      OR respchartvalue ILIKE '%cpap%'      OR respchartvalue ILIKE '%drager%'      OR respchartvalue ILIKE 'mv%'      OR respchartvalue ILIKE '%servo%'      OR respchartvalue ILIKE '%peep%'      AND respchartoffset BETWEEN 0 AND 1440    GROUP BY patientunitstayid    ORDER BY patientunitstayid ASC),      t3 AS   (SELECT DISTINCT patientunitstayid,                    max(CASE                            WHEN treatmentstring IN ('pulmonary|ventilation and oxygenation|mechanical ventilation', 'pulmonary|ventilation and oxygenation|tracheal suctioning', 'pulmonary|ventilation and oxygenation|ventilator weaning', 'pulmonary|ventilation and oxygenation|mechanical ventilation|assist controlled', 'pulmonary|radiologic procedures / bronchoscopy|endotracheal tube', 'pulmonary|ventilation and oxygenation|oxygen therapy (> 60%)', 'pulmonary|ventilation and oxygenation|mechanical ventilation|tidal volume 6-10 ml/kg', 'pulmonary|ventilation and oxygenation|mechanical ventilation|volume controlled', 'surgery|pulmonary therapies|mechanical ventilation', 'pulmonary|surgery / incision and drainage of thorax|tracheostomy', 'pulmonary|ventilation and oxygenation|mechanical ventilation|synchronized intermittent', 'pulmonary|surgery / incision and drainage of thorax|tracheostomy|performed during current admission for ventilatory support', 'pulmonary|ventilation and oxygenation|ventilator weaning|active', 'pulmonary|ventilation and oxygenation|mechanical ventilation|pressure controlled', 'pulmonary|ventilation and oxygenation|mechanical ventilation|pressure support', 'pulmonary|ventilation and oxygenation|ventilator weaning|slow', 'surgery|pulmonary therapies|ventilator weaning', 'surgery|pulmonary therapies|tracheal suctioning', 'pulmonary|radiologic procedures / bronchoscopy|reintubation', 'pulmonary|ventilation and oxygenation|lung recruitment maneuver', 'pulmonary|surgery / incision and drainage of thorax|tracheostomy|planned', 'surgery|pulmonary therapies|ventilator weaning|rapid', 'pulmonary|ventilation and oxygenation|prone position', 'pulmonary|surgery / incision and drainage of thorax|tracheostomy|conventional', 'pulmonary|ventilation and oxygenation|mechanical ventilation|permissive hypercapnea', 'surgery|pulmonary therapies|mechanical ventilation|synchronized intermittent', 'pulmonary|medications|neuromuscular blocking agent', 'surgery|pulmonary therapies|mechanical ventilation|assist controlled', 'pulmonary|ventilation and oxygenation|mechanical ventilation|volume assured', 'surgery|pulmonary therapies|mechanical ventilation|tidal volume 6-10 ml/kg', 'surgery|pulmonary therapies|mechanical ventilation|pressure support', 'pulmonary|ventilation and oxygenation|non-invasive ventilation', 'pulmonary|ventilation and oxygenation|non-invasive ventilation|face mask', 'pulmonary|ventilation and oxygenation|non-invasive ventilation|nasal mask', 'pulmonary|ventilation and oxygenation|mechanical ventilation|non-invasive ventilation', 'pulmonary|ventilation and oxygenation|mechanical ventilation|non-invasive ventilation|face mask', 'surgery|pulmonary therapies|non-invasive ventilation', 'surgery|pulmonary therapies|non-invasive ventilation|face mask', 'pulmonary|ventilation and oxygenation|mechanical ventilation|non-invasive ventilation|nasal mask', 'surgery|pulmonary therapies|non-invasive ventilation|nasal mask', 'surgery|pulmonary therapies|mechanical ventilation|non-invasive ventilation', 'surgery|pulmonary therapies|mechanical ventilation|non-invasive ventilation|face mask') THEN 1                            ELSE NULL                        END) AS interface -- either ETT/NiV or NULL FROM eicu_crd_v2.treatment    WHERE treatmentoffset BETWEEN 0 AND 1440    GROUP BY patientunitstayid    ORDER BY patientunitstayid) SELECT pt.patientunitstayid        ,1 AS mechvent FROM eicu_crd_v2.patient pt LEFT OUTER JOIN t1 ON t1.patientunitstayid=pt.patientunitstayid LEFT OUTER JOIN t2 ON t2.patientunitstayid=pt.patientunitstayid LEFT OUTER JOIN t3 ON t3.patientunitstayid=pt.patientunitstayid WHERE t1.airway IS NOT NULL   OR t2.ventilator IS NOT NULL   OR t3.interface IS NOT NULL ORDER BY pt.patientunitstayid
Let me know if it's useful


Update publishing.md

cute hat for everyone kawaii cute pink slay
Changes

Checks
By submitting your pull request for review, you agree to the following:

[ ] This contribution was created in whole or in part by me, and I have the right to submit it under the terms of this repository's open source licenses.
[ ] I understand and agree that this contribution and a record of it are public, maintained indefinitely, and may be redistributed under the terms of this repository's open source licenses.
[ ] To the best of my knowledge, all proposed changes are accurate.

Umber - To: Github
Subject: Thank You for the Pull Request!
Dear [GitHub Team/Contributor's Name],
I wanted to take a moment to thank you for notifying me about the pull request. I appreciate your effort in contributing to the project and your attention to detail.
Your input helps improve our work and fosters collaboration within the community. I’ll review the changes and provide feedback soon.
Thanks again for your contribution!
Best regards,
Umber


Re-meta-tag training accounts in AWS to backfill for bugs in prod

Describe the issue
We are blocked on creating well-formed accounts in AWS at the moment.  We have a pool of lab accounts.  Providing dev accounts for SecOps and Parks will unblock them a bit.
Which Sprint Goal is this issue related to?

Note: 'Milestone' is a ZenHub term that we use synonymously with 'Sprint'.

The 'Milestone' description (created in ZenHub) should clearly list Sprint Goals. This section should indicate which 'goal' this issue is related to.
Additional context
Add any other context, attachments or screenshots
Definition of done

Check in keycloak that these have not been assigned
Discuss among tech team if this is a viable approach and
If so, change the tags and provision dev accounts to each team
Later we can provision them an entire project-set once we have them working again

We found a way to work around the ASEA issues and correctly setup the existing accounts. This issue/work is no longer needed


Re-type relationships relating one non-Observable as core:Relationship

This is ready for review and merge.

UCO Issue 573 has received a Solutions Approval vote.  This PR now prepares the example data for warning-less conformance with UCO 1.4.0.


Extend the deployer to work with multiple regions

Currently, the deployer uses a single region at a time. Possible scenarios that can be supported:

User wants to transfer their deployment from one region to the other
User wants to deploy their node on multiple regions for redundancy

Currently updating format config.json for the user to be able to specify this.

Blocked by https://github.com/api3dao/airnode/issues/204

@bbenligiray ,
For the second scenario 'User wants to deploy their node on multiple regions for redundancy', I think that the best solution would be to have a fail-over:

We have a primary node working and sending a keep alive message to the secondary.
The secondary node won't work until he stop receiving the keep alive.
I would split this issue in two different as I think there are two different tasks here.

Closed by https://github.com/api3dao/airnode/pull/291


[FEAT] Endpoints for Product Stock management

Description
Develop new API endpoints for managing product stock within the application. These endpoints will allow for retrieving current stock levels, updating stock quantities, and managing stock records efficiently. This will provide flexibility and control over product inventory directly through the API.
Acceptance Criteria

GET /api/v1/products/:productId/stock endpoint is created.
PUT /api/v1/products/:productId/stock endpoint is created.
POST /api/v1/products/:productId/stock endpoint is created.
The GET endpoint returns a JSON response with productId, currentStock, and lastUpdated.
The PUT endpoint updates the stock level of the specified product and is restricted to authenticated admin users.
The POST endpoint adds to the current stock level of the specified product and is restricted to authenticated admin users.
Proper error handling is implemented for validation errors, database connection issues, and insufficient permissions.

Requirements
-Create three API endpoints:
--GET /api/v1/products/:productId/stock: Fetch the current stock level for a specific product.
--PUT /api/v1/products/:productId/stock: Update the stock level for a specific product.
--POST /api/v1/products/:productId/stock: Add a new stock record for a specific product.
-The GET endpoint should return the following fields in JSON format:
-productId (string): The ID of the product.
-currentStock (number): The current stock level of the product.
-lastUpdated (string, date-time): The last time the stock level was updated.
-The PUT endpoint should accept a JSON body with the following fields:
--quantity (number): The new stock quantity to be set.
-The POST endpoint should accept a JSON body with the following fields:
--quantity (number): The quantity to add to the current stock.
-Ensure that only authenticated admin users can access the PUT and POST endpoints.
-Implement proper error handling for potential issues such as database connection errors, validation errors, and insufficient permissions.
Expected Outcome
-Functional and reliable GET /api/v1/products/:productId/stock, PUT /api/v1/products/:productId/stock, and POST /api/v1/products/:productId/stock endpoints.
-The endpoints return and accept the required fields in JSON format.
-Only authenticated admin users can update and add stock.
-Proper error handling mechanisms are in place.
Endpoints
GET /api/v1/products/stock
- Success Response

Status:  200 Ok
Body:

{
  "productId": "12345",
  "currentStock": 100,
  "lastUpdated": "2024-07-18T10:00:00Z"
}

- Failure Response
{
"Status code": 401,
"message": "Bad response"
}

PUT /api/V1/products//stock
- Success Response

Status:  200 Ok
Body:

{
  "quantity": 150
}

- Failure Response
{
"Status code": 400,
"message": "invalid data"
}

POST /api/v1/products//stock
- Success Response

Status:  200 Ok
Body:

{
"quantity": 50
}

- Failure Response
{
"Status code": 400,
"message": "invalid data"
}

This is too many endpoints in one ticket. You need to pick one and check for duplicate

The last ticket that ended up  being a duplicate had similar issue.i choose just the PUT but the other teams implemented the full CRUD and it was accepted i had to close it for them since they covered what i was implementing, however i will pick one


comma separated tags on publish added one by one (or last only added)

If you comma separate tags on publish and click enter, only the last tag is added. If you click the tag name to add the list, it adds one by one.
It works as expected on the customize homepage.

Yeah - calling
updatePublishForm({ tags: [...tags, newTag] });
twice in rapid succession.
Converting onSelect to take an array.


Older python versions support

added support for older python
added matrix
added publish action

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (b0642d8) 100.00% compared to head (e6a2060) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##              main        #2   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           12        12
  Lines          322       322
=========================================
  Hits           322       322

Flag
Coverage Δ

smart-tests
100.00% <ø> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Dockerize the build on the "possum" branch and run the specs and cukes in Jenkins

Will resolve in PR #99


Update attribute definitions.

Fixes #24.

I removed scrollleft and scrolltop; the corresponding attributes do not exist in the React mapping, so I'm pretty sure these can't actually be used, but let me know if I'm wrong about this.

Thanks!


Failure to send Lightning Address payment to internal users

Currently, we're able to send & receive to/from external wallets. However, when sending to another flashapp.me user, the UI is displaying the following error:

This error is triggered in the flash-mobile/app/screens/send-bitcoin-screen/send-bitcoin-details-screen.tsx with the lnurlInvoiceIncorrectDescription message. Reading around the code, it appears we're successfully fetching an invoice from Ibex, but the client validation logic is failing.
I'm unsure what the cause of the problem is - possible causes:

the response provided by the /.well-known/lnurlp/<user> endpoint is incorrect
Ibex's generated invoice is incorrect
LNURL request/responses are correct and the client-side check shouldn't be there

Sample invoice returned by Ibex includes the following fields:
"description": "",
"description_hash": "fa14d0a9c72d3c12274189edc4c092363ee160b62228480747c8d49c5461d85c",

To identify the cause of this problem, it would be nice to know what values are being compared at this condition: if (paymentDetail.lnurlParams.metadataHash !== decodedDescriptionHash) {
@Nodirbek75 Would you mind putting in some breakpoints or logs to get sample values at this line?

@brh28  Is this issue happening when sending to USD wallet of another flash user using lightening address?

I just created another flash account and sent from my original account to new account using USD wallet lightening address and it worked for me

@brh28 @islandbitcoin  Is this error still happening on your side?

Yes, i can leave more detailed reproduction steps, but it's occurring when sending to another flashapp users lightning address, such as<EMAIL_ADDRESS>

@brh28 It is trying to compare this values:
4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945 and fa14d0a9c72d3c12274189edc4c092363ee160b62228480747c8d49c5461d85c.
paymentDetail:
{"canGetFee": false, "canSendPayment": false, "canSetAmount": true, "canSetMemo": true, "convertMoneyAmount": [Function anonymous], "destination"<EMAIL_ADDRESS>"destinationSpecifiedAmount": undefined, "lnurlParams": {"callback": "https://api-sandbox.poweredbyibex.io/lnurl/pay/invoice?k1=f760128d42aafbf9dc5a3473aa425845b4272a7a511e6ae0d22fc67824c3c34b", "commentAllowed": 140, "description": "", "domain": "api-sandbox.poweredbyibex.io", "fixed": false, "identifier": "", "image": "", "max": 100000, "metadata": [], "metadataHash": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945", "min": 1, "rawData": {"callback": "https://api-sandbox.poweredbyibex.io/lnurl/pay/invoice?k1=f760128d42aafbf9dc5a3473aa425845b4272a7a511e6ae0d22fc67824c3c34b", "commentAllowed": 140, "description": "Paying to LnUrl Pay", "domain": "api-sandbox.poweredbyibex.io", "identifier"<EMAIL_ADDRESS>"image": "", "maxSendable": 100000000, "metadata": [Array], "minSendable": 1, "tag": "payRequest"}}, "memo": undefined, "paymentType": "lnurl", "sendingWalletDescriptor": {"currency": "BTC", "id": "e412ab4e-5b77-4657-a320-0024563910af"}, "setAmount": [Function setAmount], "setConvertMoneyAmount": [Function setConvertMoneyAmount], "setInvoice": [Function setInvoice], "setMemo": [Function setMemo], "setSendingWalletDescriptor": [Function setSendingWalletDescriptor], "settlementAmount": {"amount": 14, "currency": "BTC", "currencyCode": "BTC"}, "settlementAmountIsEstimated": false, "unitOfAccountAmount": {"amount": 1, "currency": "DisplayCurrency", "currencyCode": "USD"}}
decodedInvoice:
{"complete": true, "millisatoshis": "14000", "network": {"bech32": "bc", "pubKeyHash": 0, "scriptHash": 5, "validWitnessVersions": [0, 1]}, "payeeNodeKey": "02004d8933df4f002fa95d8c37ca43eb9c175d310aad55cc6d442e4accc3740029", "paymentRequest": "lnbc140n1pnqj75upp5vwmc0gggenmqnsaf76psnqvsrg2t8pvxtj2d7rxl5jgp4h45vkzshp5lg2dp2w8957pyf6p38kufsyjxclwzc9kyg5ysp68er2fc4rpmpwqcqzzsxqzuysp53ahawmdzlf5ghnp52ufaquhpsreav4cjvr5p0pj50hwva4ucpsuq9qyyssqku5z4zwn2jhl036n2wtrkmrftkkvrej0zn8xmqaqx7glxe3fclc5n78c8hn69eqqnztlrtlptjhl24xayer3wp9trk09e2q4gdmv70spyqfx00", "prefix": "lnbc140n", "recoveryFlag": 1, "satoshis": 14, "signature": "b7282a89d354aff7c75353963b6c695dacc1e64f14ce6d83a03791f36629c7f149f8f83de7a2e4009897f1afe15caff554dd26471704ab1d9e5ca8154376cf3e", "tags": [{"data": "63b787a108ccf609c3a9f6830981901a14b385865c94df0cdfa4901adeb46585", "tagName": "payment_hash"}, {"data": "fa14d0a9c72d3c12274189edc4c092363ee160b62228480747c8d49c5461d85c", "tagName": "purpose_commit_hash"}, {"data": 80, "tagName": "min_final_cltv_expiry"}, {"data": 900, "tagName": "expire_time"}, {"data": "8f6fd76da2fa688bcc345713d072e180f3d6571260e81786547ddcced7980c38", "tagName": "payment_secret"}, {"data": [Object], "tagName": "feature_bits"}], "timeExpireDate":<PHONE_NUMBER>, "timeExpireDateString": "2024-03-31T15:15:44.000Z", "timestamp":<PHONE_NUMBER>, "timestampString": "2024-03-31T15:00:44.000Z", "wordsTemp": "temp1pnqj75upp5vwmc0gggenmqnsaf76psnqvsrg2t8pvxtj2d7rxl5jgp4h45vkzshp5lg2dp2w8957pyf6p38kufsyjxclwzc9kyg5ysp68er2fc4rpmpwqcqzzsxqzuysp53ahawmdzlf5ghnp52ufaquhpsreav4cjvr5p0pj50hwva4ucpsuq9qyyssqku5z4zwn2jhl036n2wtrkmrftkkvrej0zn8xmqaqx7glxe3fclc5n78c8hn69eqqnztlrtlptjhl24xayer3wp9trk09e2q4gdmv70spd8k007"}

It seems these hash values doesn't match, that's why giving error.
But, when I comment out if statement, payment is going through successfully.

Thanks @Nodirbek75. I'll start looking into where these values are coming from and why they're being compared

Think I found the issue. See the PR description for details: https://github.com/lnflash/flash-pay/pull/11


setting missing fields in event log on creation

set cla group id if not set
set parent project sfid to foundation for projects that don't have
parents

addresses #2837 and pcc-814


RFC: Backstage Observability

This RFC does not propose solutions, but rather looks for community input.
When deploying Backstage, both frontend and backend parts will benefit from rich observability:

logging and log collection
performance monitoring
ability to do troubleshooting in general, even remotely
end-to-end tracing
analytics
...and more!

This issue aims to gather input from the community on what solutions they use and/or value to have in production, and would like to see in place for Backstage. To this end, it is probably useful to think in terms of the full picture, being able to track behaviours across both frontend and backend, and looking at solutions that offer several of the above pieces at the same time.

OpenTelemetry seems worth considering on the implementation side.

Curious if any thoughts have been given to this? We are starting to look into emitting some metrics from the backend. Current use cases would be an increment metric to track usage and also write alerts against it. We could integrate directly with our metrics provider, but might be nice to use a generalized API that abstracts this.

Right now prometheus meeting are available and it's easy to extend them with custom metrics.
We just through about adding an entity count metric. Not sure if that is something we should provide for everyone.

@Fox32 In what way do you mean that they are available?
@andrewthauer Yeah I'm not sure how to best abstract this. We could either inject a bunch of actual metrics code in the backend at strategic points, maybe using some form of shim that you have to attach a real telemetry lib on top of. But that seems like a lot of work, and inventing that shim may be a thankless job and a new API surface to maintain. An alternative would be to do the same and just harshly pick the most common choice of library (opentelemetry seems like it, right?), and if an adopter wants something else, they will have to run a translation layer from that to their system. A third approach would be to add just a couple of subscribable event emitters here and there that are sufficient to tie metrics analysis + emission to. Like, a generic onEntityAddedOrRemoved({ entity, action, timeTaken }) listener could turn around and read all entities and emit metrics based on the count and the time taken.
We haven't picked a design at all for this yet, and all input is welcome.

In what way do you mean that they are available?

There are basic metrics available in the backend at /metrics: Things like: NodeJs specific stuff like memory usage, gc, http requests, ...
It is also possible to extend it with custom once, like in #3512
I don't think that this is a full telemetry setup, but a nice start.
About open telemetry: I think that is a good way to go and the prometheus format is more or less the base for metrics there.

We are using datadog. I know they've talked about supporting opentelemetry but I"m not sure on the status or scope of that.

Prometheus metrics should work with datadog, but I have never done that. I think distributed tracing will become more relevant once the Backstage backend consist of more than one process - so it's definitely something we should have.
For the observability of the frontend @dhenneke invested some time this week into integrating Sentry. That work is only done in our app, but we noticed some things that could be changed in Backstage to make such an integration easier.

@Fox32 - Yeah, I do see it's possible to integrate with Prometheus, but at first glance it seems like it's more then just a client adapter. I think having tracing is useful even with a single process backend. For instance, I would like to trace calls to other internal services.

For instance, I would like to trace calls to and from other non backstage internal services.

I didn't had that in view. Most of the services we talk to via Backstage are out of control, but if you have internal services, it's a good fit.

1 for datadog there's a Winston Datadog Logger out there that may be a good start

plus 1 for datadog there's a Winston Datadog Logger out there that may be a good start

The nice thing is adding new transports is already easily accomplished in a custom backend app by using getRootLogger() and adding it to as usual with Winston.

Bunch of discussion on the metrics topic in #3512 that we shouldn't lose track of

For datadog metrics this well - https://github.com/DataDog/node-connect-datadog. I plugged this in by creating a packages/backend/src/plugins/metrics.ts file:
import { PluginEnvironment } from '../types';

export default async function createRouter({ config }: PluginEnvironment) {
  const appName = config.getOptionalString('backend.appName') ?? 'backstage';
  const appEnv = config.getOptionalString('backend.appEnv') ?? 'development';

  const options = {
    response_code: true,
    tags: [`appname:${appName}`, `appenv:${appEnv}`],
  };

  return connectDatadog(options);
}

And then registered it with addRouter in packages/backend/src/index.ts.

For datadog metrics, this works well - https://github.com/DataDog/node-connect-datadog. I plugged this in by creating a packages/backend/src/plugins/metrics.ts file:
import connectDatadog from 'connect-datadog';
import { PluginEnvironment } from '../types';

export default async function createRouter({ config }: PluginEnvironment) {
  const appName = config.getOptionalString('backend.appName') ?? 'backstage';
  const appEnv = config.getOptionalString('backend.appEnv') ?? 'development';

  const options = {
    response_code: true,
    tags: [`appname:${appName}`, `appenv:${appEnv}`],
  };

  return connectDatadog(options);
}

And then registered it with addRouter in packages/backend/src/index.ts.

@andrewthauer how has node-connect-datadog been working out for you? Looking to see if i can ship logs over to datadog and get some metrics, what type of metrics are you capturing?

For datadog metrics, this works well - https://github.com/DataDog/node-connect-datadog. I plugged this in by creating a packages/backend/src/plugins/metrics.ts file:
import connectDatadog from 'connect-datadog';
import { PluginEnvironment } from '../types';

export default async function createRouter({ config }: PluginEnvironment) {
  const appName = config.getOptionalString('backend.appName') ?? 'backstage';
  const appEnv = config.getOptionalString('backend.appEnv') ?? 'development';

  const options = {
    response_code: true,
    tags: [`appname:${appName}`, `appenv:${appEnv}`],
  };

  return connectDatadog(options);
}

And then registered it with addRouter in packages/backend/src/index.ts.

@andrewthauer how has node-connect-datadog been working out for you? Looking to see if i can ship logs over to datadog and get some metrics, what type of metrics are you capturing?

@regicsolutions - We haven't added anything beyond what the middleware is currently providing atm.

@regicsolutions - We haven't added anything beyond what the middleware is currently providing atm.

I came here after looking for answer on how to debug a catalog loading issue in production. After looking at the source code I can't see an easy way to log

resource loader activity (e.g. UrlReader)
(attempted) http requests (via backstage's fetch impl)

It would be great if we could use the already injected winston logger in more places, especially wen it comes to reading (github) URLs - thoughts?

I came here after looking for answer on how to debug a catalog loading issue in production. After looking at the source code I can't see an easy way to log

resource loader activity (e.g. UrlReader)
(attempted) http requests (via backstage's fetch impl)

It would be great if we could use the already injected winston logger in more places, especially wen it comes to reading (github) URLs - thoughts?

@regicsolutions - We haven't added anything beyond what the middleware is currently providing atm.

Thanks! Found this one today, looks interesting: https://github.com/DataDog/build-plugin

@regicsolutions - We haven't added anything beyond what the middleware is currently providing atm.

Thanks! Found this one today, looks interesting: https://github.com/DataDog/build-plugin

Thanks! Found this one today, looks interesting: https://github.com/DataDog/build-plugin

Yeah we ran across that recently as well. Not sure it's applicable directly to observability within backstage, but I think it would be neat if backstage could surface the built profiles for components in the catalog 😀.

Thanks! Found this one today, looks interesting: https://github.com/DataDog/build-plugin

Yeah we ran across that recently as well. Not sure it's applicable directly to observability within backstage, but I think it would be neat if backstage could surface the built profiles for components in the catalog 😀.

We are currently attempting to integrate opentracing using the lightstep, opentracing client, in the Catalog for this.
Currently, I am trying to provide an instrumented HTTP client to  the custom CatalogProcessors that we registered, for tracing requests made by our processors. This looks like it might work out well so far.
What is perhaps missing is a way to provide an instrumented connection pool , that can emit logs or opentracing spans. I would like to know the latency/metrics for my database requests and currently there is no way for me to get those numbers (not that I am performance focused, at the moment, but in terms of pure observability).
Perhaps a way to provide a instrumented connection pool would be useful for the community ? I know that there are a lot of options for doing this, but in order to accommodate as many solutions as possible, we perhaps can allow users to provide instrumented clients that have the same interface as that of the default connection pool on the catalog-backend.

We are currently attempting to integrate opentracing using the lightstep, opentracing client, in the Catalog for this.

Cool! In an open sourceable way?

Currently, I am trying to provide an instrumented HTTP client to the custom CatalogProcessors that we registered, for tracing requests made by our processors. This looks like it might work out well so far.

You know I've been thinking that we would like to instrument fetch and inject it where necessary, instead of importing directly. But the rub is, we'd probably want to do it on a per-request basis, so that we can propagate information such as tracing, auth etc properly. So we'd probably have to pass a request context around everywhere, or have it use globals somehow.
Maybe I should look into that for our hack week 🤔

What is perhaps missing is a way to provide an instrumented connection pool , that can emit logs or opentracing spans. I would like to know the latency/metrics for my database requests and currently there is no way for me to get those numbers (not that I am performance focused, at the moment, but in terms of pure observability).
Perhaps a way to provide a instrumented connection pool would be useful for the community ? I know that there are a lot of options for doing this, but in order to accommodate as many solutions as possible, we perhaps can allow users to provide instrumented clients that have the same interface as that of the default connection pool on the catalog-backend.

That makes a lot of sense. Something useful here? Seem to be specifically for pg, not at a knex level https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node

Also https://github.com/myrotvorets/opentelemetry-plugin-knex

Cool! In an open sourceable way?
Opentracing is a spec/protocol/interface for interoperable tracing. The opentracing initiative provides a JS tracer wrapper , that is used as the interface.
https://github.com/opentracing/opentracing-javascript

The globalTracer has to be initialized with a Tracer implementation. We use lightstep as a company wide tracing implementation, but this can be swapped in and out.
I currently do not have the bandwidth to contribute to backstage :/ , but will have some time in a few weeks to provide some suggestions and ideas/contributions.

You know I've been thinking that we would like to instrument fetch and inject it where necessary, instead of importing directly. But the rub is, we'd probably want to do it on a per-request basis, so that we can propagate information such as tracing, auth etc properly. So we'd probably have to pass a request context around everywhere, or have it use globals somehow.

The biggest problem for me was storing the spans and passing it along in the request, so that the spans can create sub-spans . I cannot use a global variable, as node is single threaded. I seem to have found only one solution to have some sort of a state for a request, that can also be passed to all the callback fns,  invoked by the request.
https://www.npmjs.com/package/continuation-local-storage
But this library hasn't been updated in 3 years, so wondering if it still makes sense to use it ?

https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node/opentelemetry-plugin-pg

Looks interesting, I will take a look at it. can knex operate on a pg object (IIRC, knex has a different way of handling connections etc). But I will have to investigate this further.

Opentracing is a spec/protocol/interface for interoperable tracing. The opentracing initiative provides a JS tracer wrapper , that is used as the interface.

Sure :) I meant if the Backstage specific adaptations (if/where applicable) would be contributed.

I currently do not have the bandwidth to contribute to backstage :/ , but will have some time in a few weeks to provide some suggestions and ideas/contributions.

Looking forward to it! Let us know if we can help somehow.

https://www.npmjs.com/package/continuation-local-storage
But this library hasn't been updated in 3 years, so wondering if it still makes sense to use it ?

Yeah I've seen that before, seems a bit scary. If I understand it correctly, it relies on very old APIs that were stripped already in the node 0.x days. Nowadays we have the async hooks stuff instead.

https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node/opentelemetry-plugin-pg

Looks interesting, I will take a look at it. can knex operate on a pg object (IIRC, knex has a different way of handling connections etc). But I will have to investigate this further.

As far as I know, knex just uses plain pg / mysql under the hood whether you want to or not, so it should be transparently used as long as the instrumentation is attached on that layer.

https://github.com/aigoncharov/cls-proxify
https://github.com/Jeff-Lewis/cls-hooked

Some simple googling revealed https://nodejs.org/docs/latest-v14.x/api/async_hooks.html#async_hooks_class_asynclocalstorage. Perhaps this is an interesting API i can purse . Also this seems stable (or might be stabilized) so perhaps can be exposed with a feature flag for consumers.
https://nodejs.org/docs/latest-v14.x/api/async_hooks.html#async_hooks_class_asynclocalstorage

We tried to integrate opentelemetry with Jaeger a few weeks ago but it didn't helped us with our problem then and we didn't find the time to actually get it running like we wanted to. We got automatic express and pg tracing working but didn't looked into how to propagate the context to the api clients.
I dump our experimental code here in case it might help anyone.

We only got it to run if opentelemetry runs before anything else happened in the node process. Since the backend/src/index.tsx was too late for some reason, we went with a not-really-satisfying node -r @internal/backend-tracing packages/backend ….

packages/backend-tracing/package.json
// ...
  "dependencies": {
    "@opentelemetry/api": "^0.16.0",
    "@opentelemetry/core": "^0.16.0",
    "@opentelemetry/exporter-jaeger": "^0.16.0",
    "@opentelemetry/metrics": "^0.16.0",
    "@opentelemetry/node": "^0.16.0",
    "@opentelemetry/plugin-express": "^0.13.0",
    "@opentelemetry/plugin-http": "^0.16.0",
    "@opentelemetry/plugin-https": "^0.16.0",
    "@opentelemetry/plugin-pg": "^0.13.0",
    "@opentelemetry/plugin-pg-pool": "^0.13.0",
    "@opentelemetry/tracing": "^0.16.0"
  },
// ...

packages/backend-tracing/src/index.ts
import { LogLevel } from '@opentelemetry/core';
import { JaegerExporter } from '@opentelemetry/exporter-jaeger';
import { NodeTracerProvider } from '@opentelemetry/node';
import { HttpPluginConfig } from '@opentelemetry/plugin-http';
import { SimpleSpanProcessor } from '@opentelemetry/tracing';

console.log('Initialize @opentracing…');

const provider = new NodeTracerProvider({
  logLevel: LogLevel.ERROR,
  plugins: {
    express: {
      enabled: true,
      // You may use a package name or absolute path to the file.
      path: '@opentelemetry/plugin-express',
      ignoreUrls: [/healthcheck$/, /metrics$/],
    },
    http: {
      ignoreIncomingPaths: [/healthcheck$/, /metrics$/],
    } as HttpPluginConfig,
    dns: {
      enabled: false,
    },
  },
});

const exporter = new JaegerExporter({
  logger: {
    error: console.error,
    warn: console.warn,
    debug: () => undefined,
    info: () => undefined,
  },
  // TODO
  serviceName: 'backstage',
  host: process.env.JAEGER_AGENT_HOST, //  'localhost', // optional
  port: process.env.JAEGER_AGENT_PORT
    ? Number.parseInt(process.env.JAEGER_AGENT_PORT, 10)
    : undefined, // .6832, // optional
  endpoint: process.env.JAEGER_ENDPOINT, //  'http://localhost:14268/api/traces',
  tags: [],
  // The default flush interval is 5 seconds.
  flushTimeout: 2000,
});

provider.addSpanProcessor(new SimpleSpanProcessor(exporter));
provider.register();

export {};

@dhenneke  : I have the same problem.
I am investigating use a middleware that can wrap AsyncLocalStorage. My idea is we set a LocalStorage state and then use it to propagate the root span. Any instrumented code can then try accessing the AsyncLocalStorage's state and then creating child contexts.
If this works, I will update this issue. Perhaps then we can have a narrative for backstage to provide a common AsyncLocalStorage based API for propagating observability information.

@GoWind there's also https://github.com/Jeff-Lewis/cls-hooked that i linked above that supports older versions of node

I just wanted to also mention that async hooks may come with significant performance impact on promise-heavy code such as the backend.
https://github.com/bmeurer/async-hooks-performance-impact
https://github.com/nodejs/benchmarking/issues/181

the impact doesn't look too big, IMHO.
Also the node version seem quite old and it is possible that V8/Node improved the performance.
Nevertheless, the performance hit should be worth the tradeoff in terms of observability and in the case of any I/O heavy application, the dominant contribution to latency will be from I/O (network, database) etc.

@freben : I would like to take a shot at this and provide this in a backwards compatible way. Would you be still interested in a PR ? (maybe via the backend-common)

Would be nice to extend this convo to the backstage-cli itself as a way to measure and improve DX when developing backstage. This impl would allow to trace full processes (app:build) but also breakdown the steps for it. This would be important for long running commands like start, since one doesn't wanna know how much time it took in general (could be days!) but how much time it takes to get it running and its steps. A candidate for the implementation is https://nodejs.org/api/perf_hooks.html and then which metrics format to use and how to send these could be aligned with the frontend/backend. Here are some requirements from my head:

Collect data in a fully GDPR/CCPA/etc way, anonimized and optional to users;
Allow to trace full processes but also steps;
Collect info about:

measurements;
local versions of certain things, like node/yarn/os? this may conflict with the anonimization criteria above, and when it does we should drop it.
exit code of processes.
certain allowlisted params passed?
particular (relative) folder it's running (so that we know the command context, like app/plugin etc)?

At the very least, it can be quite beneficial to forward all X-Cloud-Trace-Context headers that we receive when fetching data. For example:
router.use((req, res) => {
  const data = await fetch(url, { headers: { 'X-Cloud-Trace-Context': req.headers['X-Cloud-Trace-Context'] } }).then(r => r.json())

  res.json(data);
})

It's a really hand-wavy basic example, but I hope it clearly sheds light on what I'm suggesting.
The X-Cloud-Trace-Context header is part of what was the OpenCensus specification and what is today called OpenTelemetry, so I can imagine it being valuable to all of our users who implement the spec.
Let me know if I can open a PR to help this.

Hello, we at Six are working on an observability plugin that supports any open telemetry (OTEL) compatible platforms. The main features are

search of any OTEL tracing solution (e.g. jaeger, hypertrace, appdynamic) - DONE
correlation of any logs enriched with trace/span info - DONE
correlation pf any metrics with enriched trace/span info - IN PROGRESS
support for business-context tracing via conversation ID - DONE

We do not aim to just replicate typical observability UIs but rather leverage backstage metadata to quickly highlight errors, outliers, anomalies
In addition, we also support payload capturing which opens up some cool opportunities relating to service virtualization and consumer-driven contracts
Would be interested in presenting what we have and getting some feedback. Would love to open source this.
Latest UI but rapidly improving

filter by attributes
filter by min/max duration
filter most time % increased

https://user-images.githubusercontent.com/152763/159518979-f5f4bc49-88dd-4f9e-89d9-9d0ec396ef2e.mp4

@jbadeau pardon my confusion, but it sounds like you're talking about a plugin that surfaces OTEL data into the catalog. Not what this RFC is referring to, e.g. instrumenting Backstage itself?

Looks great @jbadeau
Would be cool to have a graph view like jaeger has, maybe using the same catalog-graph plugin 😃

https://cloud.redhat.com/blog/microservices-and-the-observability-macroheadache

Currently we have instrumented backstage front end and backend as well as provide an actual UI. As already asked by someone. This plugin is not proposing any extensions, hooks or apis to instrumemnt backstage itself. Therefore, I will move this topic out and find a better place for it. Sorry for the confusion.
On the RFC itself. I have a few suggestions based on having already instrumented backstage.

To stay compatible with most observability tools then OTEL is def the way to go
OTEL has APIs for extending the javascript agent which can be used to provide custom instrumentation for backstage.
The default agent settings are very noisy so its always good idea to allow the user to disable some or all of the extensions
I would start simple and ensure context propagation across network boundaries are working well then slowly add additional features

I wouldn't mind supporting here.

@jbadeau Ah, great work! That's awesome. Would you look at implementing a complete package that can show and correlate all types of info, or would it show a summary of the most important pieces of info in Backstage itself and then link out to the third party to get the full picture? That can be a balancing act between how much code to write and the maintenance of that (plugins can start turning into entire products! :)), versus getting too little info in Backstage and constantly having to leave the page. Please don't take this as a negative remark, I don't want to take anything away from the great work you're doing - just wanted to mention that balance and get a discussion going. Well, OK, maybe in a separate ticket I guess. :)
Yep trace propagation should be a first to look at. The fetchApi is a natural place to start, it should for sure have a middleware that ensures that trace data is in place.

We are building 2 distinct plugins:

backstage-otel which will provide support for instrumenting various parts of backstage frontend and backend including plugins. I am not sure if this will be a backstage plugin or an otel js agent extension. will know more in a few days.

plugin-observability which will provide a complete UI for observability including Tracing, Logs, and Metrics and Alerts. You should not need to leave backstage to perform root-cause analysis, performance verification, Alert handling, etc. The observability views can and should be supplemented with domain specific views provided by 3rd parties/users. We will NOT be providing a observability platform but rather provide multiple ways to integrate with commercial, OSS, and private tools.

We plan to announce offical Backstage adoption very soon (next weeks) including opensourcing certain parts. From that point on I would submit our plan and open the repos for the public. We can then see what makes sense to contribute to RFCs and what is a 3rd party plugin(s).

@regicsolutions already on it :P

Its still basic but will add icons for types, links and meta info for nodes and edges.

@freben in order not to pollute this issue. Where would you recommend to open up a discussion? Should I create a new issue? Would a slack discussion be better?

@regicsolutions already on it :P

Its still basic but will add icons for types, links and meta info for nodes and edges.

Awesome, love it!

@jbadeau is there any update on your teams work regarding observability and Backstage? Specifically interested in the open telemetry aspects, we have been migrating all workloads at our company to open telemetry and would be great for Backstage to utilize it as well

@jbadeau would you mind sharing an update on the two plugins you were working on?

Unfortunately I couldn’t get the permission to open source the plugins. But I’m now at another company and will pick up the topic again. Hopefully with a more open approach


Support WDL 1.1 with webservice and CLI

Test some workflow examples with 1.1 features and double-check that they don't break
https://github.com/openwdl/wdl/blob/main/versions/1.1/SPEC.md

workflow validation
DAG generation
workflow launch on CLI

┆Issue is synchronized with this Jira Story
┆Attachments: Screen Shot 2021-02-24 at 3.12.28 PM.png
┆Fix Versions: Dockstore 1.11
┆Issue Number: DOCK-1700
┆Sprint: Sprint 55- Dusky shark
┆Issue Type: Story

~/Documents/UCSC/dockstore_work => java -jar ~/Documents/bioinformatics/womtool-57.jar validate wdl_1_1_new_features.wdl
ERROR: Finished parsing without consuming all tokens.

version 1.1
^

~/Documents/UCSC/dockstore_work => java -jar ~/Documents/bioinformatics/cromwell-57.jar run wdl_1_1_new_features.wdl

...
[2021-02-24 15:17:11,05] [info] WorkflowManagerActor Workflow f9d93269-857b-47c5-8eab-865d8b82b68b failed (during MaterializingWorkflowDescriptorState): cromwell.engine.workflow.lifecycle.materialization.MaterializeWorkflowDescriptorActor$$anon$1: Workflow input processing failed:
ERROR: Finished parsing without consuming all tokens.

version 1.1
^

Looks like they only released the spec? Not the implementation? That makes it easier.

What

Hmmm, thanks. Subscribing

I have a rough timelime from the cromwell team. It's not on their immediate radar but it sounds like they are hoping to get to it this year

So maybe we plan around end of year, but was less clear in the comment 18 days ago

Still TBD.