Istio changes

[x] Change "service mesh" links to "Istio", Change "Cluster Service Mesh" to "Istio"
[x] Note/Warning in the UI that sidecar injection needs to be enabled for each namespace. For any existing namespaces, you will need to enable the feature and re-deploy. "In order to leverage Istio, you will need to enable Istio sidecar auto injection for each namespace. If you enable it on an existing namespace, any existing workloads will need to be re-deployed to leverage the sidecar auto injection."
[x] Add Istio icon next to namespace names for any namespace that has sidecar injection turned on.
[x] In traffic graph view, add in kiali logo with a note that says "Powered by Kiali" in the bottom right corner
[x] Add in version dropdown for istio as we did for monitoring.
[x] Enabled Mixer Policy -> Enable Mixer Policy

Version: Master (v2.3) (6/14/19)
This covered lots of little changes. I took the summary from the PR and addressed how I tested each area below. Each bullet is each change done.

Change "service mesh" links to "Istio", Change "Cluster Service Mesh" to "Istio"
https://github.com/rancher/ui/pull/3058/commits/09c43455875aff8f5213c1d04e194509dfdf8792

Confirmed that the link on the nav bar now reads "Istio" and that Tools > menu now shows "Istio" and that config page header now shows "Istio"

Note/Warning in the UI that sidecar injection needs to be enabled for each namespace. For any existing namespaces, you will need to enable the feature and re-deploy. "In order to leverage Istio, you will need to enable Istio sidecar auto injection for each namespace. If you enable it on an existing namespace, any existing workloads will need to be re-deployed to leverage the sidecar auto injection."
https://github.com/rancher/ui/pull/3058/commits/09c43455875aff8f5213c1d04e194509dfdf8792

notEnabled:

enabled:

Add Istio icon next to namespace names for any namespace that has sidecar injection turned on.
In traffic graph view, add in kiali logo with a note that says "Powered by Kiali" in the bottom right corner
https://github.com/rancher/ui/pull/3058/commits/d5636f2578d3e72c9b3b2ecf6fc5ecb14192dc44

This is to the bottom-right of the Kiali chart (Traffic Graph) and scales well and properly with various window sizes (no glitches in placement, etc). Clicking on it bring us to https://www.kiali.io/

Add in version dropdown for istio as we did for monitoring.
https://github.com/rancher/ui/pull/3058/commits/e371628a03819e5ca0a7fa4c4791d25f71797f5d

Currently, as of preview2 release, hard-coded version in the UI. This will be used later in https://github.com/rancher/rancher/issues/20617

Enabled Mixer Policy -> Enable Mixer Policy
https://github.com/rancher/ui/pull/3051

(This was already fully validated with https://github.com/rancher/rancher/issues/20840 )

Istio - Warn user that workloads will need to be re-deployed when editing sidecar auto-injection on namespace
https://github.com/rancher/ui/pull/3058/commits/4dded84ef5acd18866bb7afeefc80ab67e7978ee

Only when we edit our namespace and pick "Enabled" do we see the message.
When you create a new namespace and click "Enabled" you do NOT see the message (as expected because we could not possibly have any workloads in this ns yet).
You will see this message when you edit a namespace and Enable the auto-injection regardless if there are any workloads or not. I think this is okay.

Last, smoke tested Istio config (ensure UI and app answers match, http good, actual memory/cpu requests/limits correct, etc)


Trivy scan failing

The trivy scan is failing with TOOMANYREQUESTS, though it's only running once as far as I can tell.
https://github.com/bcgov/nr-hydrometric-rating-curve/actions/runs/11727757171/job/32730656689?pr=204
2024-11-08T18:51:04Z	WARN	'--scanners config' is deprecated. Use '--scanners misconfig' instead. See https://github.com/aquasecurity/trivy/discussions/5586 for the detail. 2024-11-08T18:51:04Z	INFO	[vulndb] Need to update DB 2024-11-08T18:51:04Z	INFO	[vulndb] Downloading vulnerability DB... 2024-11-08T18:51:04Z	INFO	[vulndb] Downloading artifact...	repo="ghcr.io/aquasecurity/trivy-db:2" 2024-11-08T18:51:05Z	ERROR	[vulndb] Failed to download artifact	repo="ghcr.io/aquasecurity/trivy-db:2" err="oci download error: failed to fetch the layer: GET https://ghcr.io/v2/aquasecurity/trivy-db/blobs/sha256:6286c928825b62501eaa5bb4cdf1b4b7ab80d303e2d7bd99e927ec1472a8509e: TOOMANYREQUESTS: retry-after: 184.863µs, allowed: 44000/minute" 2024-11-08T18:51:05Z	FATAL	Fatal error	init error: DB error: failed to download vulnerability DB: OCI artifact error: failed to download vulnerability DB: failed to download artifact from any source Error: Process completed with exit code 1.

@tobiasmllr Trivvy has been having problems. I'll make this job optional, so there won't be a block. We can reverse later.

@tobiasmllr Done!  Please see #207.  :)


Prefer mtr-tiny over mtr on Debian

Since this is designed for a server-type operating system, installing mtr-tiny on Debian would prevent pulling in ~38 dependancies. This looks like it would require another fixup if loop in the setup script.
I'm not sure if packages on RHEL based systems have a similar option, or if theirs is similar to mtr-tiny to begin with.

Possibly both and an option in the config. like MTR_BINARY=/blah/path/mtr

Add network commands to configuration #13 could do this....

 H2##


taking a long time problem;

if domain is bad，The following code is take a long time ,such as request random url "https://mnasdoiawdlkal.com/"
sorry，i'm english is bad,
const links = await (
await page.evaluateHandle(() =>
Array.from(document.getElementsByTagName('a')).map(
({ hash, hostname, href, pathname, protocol, rel }) => ({
hash,
hostname,
href,
pathname,
protocol,
rel
})
)
)
).jsonValue()

You can set maxWait to a lower value.
https://www.npmjs.com/package/wappalyzer

The default of 5 seconds is acceptable to me,
"Array.from(document.getElementsByTagName('script'))"  this code get script tag is fast,
but  "document.getElementsByTagName('a')"， only get "a" tag is long ,It's a little strange

not this problem,default 5 second is acceptable to me,i think because set maxwait，so not get document ,error show "document is not defined",so puppeteer use page.evaluateHandle execute JS get tag can take long time

I'm not seeing this behaviour even when setting maxWait to something low like 1.

oh,Maybe  my network didn't request DNS or slow
thinks


Northwest Territories: "Find out if you need to be tested" goes to Survey Monkey

v14, tested on iPhone XS
Change the region to NWT. In both the French and English versions, if the user clicks "Find out if you need to be tested", they are directed to a Survey Monkey page.

@katewilhelm can you verify the link that belongs here?

Good catch. That is the link for the NWT self-assessment, but it's probably better to link people here so they get the NWT context and assurance:
EN https://www.gov.nt.ca/covid-19/en/services/nwt-online-covid-19-self-assessment-tool
FR https://www.gov.nt.ca/covid-19/fr/services/outil-d’auto-évaluation-en-ligne-pour-la-covid-19-aux-tno


Small ResponseContinuationTokenLimitInKb leads to query execution failed with 400 status code.

Describe the bug
Seeing throughput this doc: https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.documents.client.feedoptions.responsecontinuationtokenlimitinkb?view=azure-dotnet#remarks
It says this ResponseContinuationTokenLimitInKb can be >= 0. So I set it to 0 and the request will always failed with an exception:
"Errors":["The continuation token limit specified is not large enough to serialize the required attributes into the continuation token. Please provide a higher limit."]
This behavior kind of make sense since we can't compress a token to not exist. But maybe the document could point this out to avoid misleading.
But my question is: Will this exception also happens when I set this value to 1 but the actual token string length is above 10,000?
I heard that the max size could grow to 16Kb. I can't repro a 10,000 token locally but such token does exist in our PROD env. Is it safe to set this limit to 1 or higher value like 4 and expect no failure on this token size limit reason?
And by the way, from your aspect, is it saft to pass this continuationToken directly (without mapping or encryption) to end user? Like through this token string, will they know that we are using Cosmos DB as backend database, and do something harmful with this token?
Looking forward to hearing from you.
Thanks!
To Reproduce
Excute a query and set the QueryRequestOption.ResponseContinuationTokenLimitInKb = 0;
Expected behavior
Query success.
Actual behavior
Failed with 400 exception:
"Errors":["The continuation token limit specified is not large enough to serialize the required attributes into the continuation token. Please provide a higher limit."]
Environment summary
SDK Version: tested on 3.31.0 and latest version. same behavior
OS Version: windows 11

@blankor1 thanks for the feedback, @jcocchi / @neildsh can we make the documentation around this property a bit more clear?
Regarding the expectations though, @blankor1 could you explain why do you expect a query with 0 allowed continuation to succeed? How would the query communicate the continuation for the next pages?

@ealsur Thank you! It's just that the documentation says that this value can be greater than or equal to 0 and I want to test if I can make this limit smaller than 1Kb. If 0 will always fail the query execution, maybe we can consider exclude zero from the doc description.
I have this question because we have very large continuation token size in our PROD env, and now we want to apply this size limit in our library since we would like to pass this value to frontend for pagination and token size too long may fail the request. So there is two things I really want to make sure:
1. Will this length too small exception also happens when I set this value to 1 but the actual token string length is above 10,000 or higher?
2.  Is it saft to pass this continuationToken directly (without mapping or encryption) to end user? Like through this token string, will they know that we are using Cosmos DB as backend database, and do something harmful with this token?
Do you have any suggestion or best practice about how we should apply Continuation token and this ResponseContinuationTokenLimitInKb?

Hi @blankor1 the continuation token is used to serialize data that is then used for resuming the query. If you reduce the size of the continuation token then all the work that we did to calculate this data such as the filter posting set from the index etc. will have to be redone on each subsequent round trip. This will make your queries slower and more expensive. In general, we do not recommend setting this property but just rely on the default instead.

@neildsh Thanks for your explanation. Let me clarify, For us, some extra cost and perf penalty are acceptable. But it would be unacceptable for us if the query will fail because the token is too long but we demand the token to be limited to a smaller size (non-0). So we just want to make sure whether this would happen.

My apologies for the late response @blankor1. This is correct. Smaller values should not cause failures, but we really would recommend against setting small values here. I would recommend running tests with workloads that are representative of your production environment, and logging the size of the continuation tokens generated. You can use that to calibrate the value of this setting.
For very expensive queries (for example ORDER BY, where the backend has to scan a large number of index pages), small values of the continuation token size can lead to your query hitting edge cases where you are spending a lot of time on extra round trips.


Wrap and proxy method calls for builtin objects rather than error(?)

It could be useful to do something like the following to ensure all open() calls have a corresponding close(). Unfortunately it's a lot more cumbersome ATM due to inability to directly proxy for instances of builtin objects.

real_open = open
def wrap_open(*k, *kw):
  """ this could be a lambda one-liner even"""
  f = real_open(*k, **kw)
  flexmock(f).should_call('close').with_args().once
  return f

flexmock(__builtins__, open=wrap_open)

I copied this issue to the new official repo: https://github.com/bkabrda/flexmock/issues/3 closing this one


tests: new websocket server

api.blink.sv/graphql -> main graphql
ws.blink.sv/graphql -> websocket server


prettier-plugin-toml does not seem to work using the command line

npm ls -g
/usr/local/lib
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>
$ node --version
v18.13.0
$ npm --version
9.2.0

I have Prettier and prettier-plugin-toml installed globally.
I try:
prettier --write testconfig.toml

and get:
[error] No parser could be inferred for file "/home/david/Downloads/testconfig.toml".

I also try:
prettier --plugin=prettier-plugin-toml testconfig.toml

and get:
[error] Cannot find package 'prettier-plugin-toml' imported from /home/david/Downloads/noop.js

Am I missing something here, or is there a bug? Thanks.

Maybe a prettier core bug?

Maybe a prettier core bug?

Seems unlikely, could you give an example of a command that you have used that definitely works?

Seems unlikely

How do you confirm this? I've never used global installed plugins. Did you tried any other plugin that works?

I see the same problem using npx. I cannot use the 1.0.0 release of prettier-plugin-toml. The 0.4.0 release works fine. (I'm using npx here outside of any JavaScript project.)
% npx<EMAIL_ADDRESS>prettier --tab-width 4 --write pyproject.toml
[error] No parser could be inferred for file "/Users/bruce/clo/triple-settlement-rewards-network/pyproject.toml".
% npx<EMAIL_ADDRESS>prettier --tab-width 4 --write pyproject.toml
pyproject.toml 7ms

I see the same problem using npx. I cannot use the 1.0.0 release of prettier-plugin-toml. The 0.4.0 release works fine. (I'm using npx here outside of any JavaScript project.)
% npx<EMAIL_ADDRESS>prettier --tab-width 4 --write pyproject.toml
[error] No parser could be inferred for file "/Users/bruce/clo/triple-settlement-rewards-network/pyproject.toml".
% npx<EMAIL_ADDRESS>prettier --tab-width 4 --write pyproject.toml
pyproject.toml 7ms

Thanks a lot for this reply, I finally find a way to run prettier-plugin-toml with npx and vim autocmd

Newest version of Prettier seems to need plugins set. Seems to no longer auto-load them. Either with --plugin=NAME or in configuration:
 "plugins": ["prettier-plugin-ini", "prettier-plugin-toml"]

https://prettier.io/docs/en/plugins

@Tatsh Thanks for the pointer to the Prettier documentation about plugins! Unfortunately, Prettier's --plugin option doesn't seem to work with npx 😢
% npx --package=prettier-plugin-toml prettier --plugin=prettier-plugin-toml --tab-width 4 --write pyproject.toml
[error] Cannot find package 'prettier-plugin-toml' imported from /Users/bruce/sample-pythoni/noop.js

The workaround in this comment on a Prettier issue works with npx 🎉.
% npx prettier-pnp --pn toml --tab-width 4 --write pyproject.toml

----- Already installed ----

 - prettier-plugin-toml

----- Running prettier -----

pyproject.toml 5ms

With a global install the full path to the main export must be given (.exports['.'] in package.json):
prettier --plugin=${HOME}/somewhere/node_modules/prettier-plugin-toml/lib/api.js a.toml

This can be made easier by using a global config.

So it's really a prettier core issue, I'll close this issue for now, if you still confirm it's related to this plugin instead, please raise a new issue with reproduction, thanks all.


feat(compile): use build dependencies files and improve support

Describe the changes and your approach

Verification Checklist

[ ] I performed a self-review of my changes and approve them.
[ ] I checked of the automated test results for any irregularities.
[x] I manually tested the code changes on my local environment.
[x] I considered changes to the README or test docs. (Check if not applicable.)

openSUSE compile is failing since the default package is libboost_headers1_66_0-devel but requires >=1.73.0.


Unicode characters are lost during format on save

I experience the same issue as #545 with the latest version of the CSharpier extension and VS2022.
All Unicode characters are replaced with ASCII versions or question marks during the format. For example, Š becomes S.
This is a good file for reproducing the issue:
https://github.com/apache/lucenenet/blob/master/src/Lucene.Net.Analysis.Common/Analysis/Miscellaneous/ASCIIFoldingFilter.cs
I tried to provide a failing test, but I cannot build the project on my machine.

I haven't been able to reproduce this so far.
I tried with
VS2022 Professional 64bit 17.3.0 and 17.2.5 (I think? I updated to latest after it worked on the 17.2.x version I had)
CSharpier 0.18.0
CSharpier Plugin 1.3.0
Windows 10
I tried both the right click "Reformat with CSharpier" as well as format on save.
With the interactions between the plugin and csharpier, providing a test is harder. As far as I know csharpier itself has handled unicode properly for quite a while.
Could there be something else running on save? You could disable the format on save of csharpier, and see if you still lose unicode. Files that start with // <autogenerated  also get ignored by csharpier

One thing I just thought of but am not able to test right now - this could have to do with the file encoding. When I tested, I copied the contents into a new file. I'll test with the actual file to see I can reproduce it that way.

Everything is ok. This was my fault. I checked only the version of the VS extension, but the problem was with the old version of the tool. Thanks for providing the version info. That helped me realize the problem.


Bump k8s to v1.26

Using the new base branch gloo-repo-branch based off of our gloo-edge-safe-hasher tag. To be used for tags and import in Gloo OSS.

bumps k8s dependencies to 1.26
bumps skv2

Note: skv2 went from 0.17 => 0.30, could this lead to issues? is it worth backporting the skv2 k8s upgrade to 0.17?
Note 2: I'm also working on updating k8s in solo-kit, may wait for that one before bringing in here.

undrafting, just to make sure CI runs and i can see if anything breaks/broke

CI never ran, pushing empty commit. Want to make sure this is okay to bump skv2 and bringing it in gloo doesn't break anything

CI not running. maybe due to old gh runner version? I see main does not have any github workflows, so I'm going to just bring this into my gloo branch and see if it works..

woo they ran and passed 🥳


MAINT: SPEC-007 basinhopping

@mdhaber I left the rng docstring 'sparse', waiting for a possible PR to adjust the part of the decorator that changes the docstring.

The failing test seems flaky. It passes on some platforms and fails on others. I removed the np.random.seed in the setup, but tests should be written in such a way that they don't really need a seed.

IIUC, test_gh7799 started failing occasionally after you removed the use of np.random.seed?

tests should be written in such a way that they don't really need a seed.

If the test is property-based, then yup, ideally the seed doesn't matter. Still, we seed the tests anyway to prevent failures that cannot be reproduced. (Stress-testing without many different seeds can be done locally.) Can you add rng to the flaky test and any others that are nondeterministic?
If you're concerned about the test failing sometimes, we can open a separate issue about it, but I wouldn't ask you to debug and fix it here.


Dynamic Scaling

It is mentioned that the requirements for dynamic scaling are:
1.All instances should have the same lease container configuration.
2.All instances should have the same workflow name.
3.Each instance needs to have a different instance name (WithInstanceName).
It is also mentioned that
" One lease can only be owned by one instance at a given time, so the maximum number of instances equals to the number of leases."
So to dynamically scale , must we use same leases configuration or multiple leases?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e1a5194d-0869-94e6-227f-4fba0c798b22
Version Independent ID: 47f771ee-5237-7fb5-dbc6-fcebafdec142
Content: Working with the change feed processor library in Azure Cosmos DB
Content Source: articles/cosmos-db/change-feed-processor.md
Service: cosmos-db
GitHub Login: @rimman
Microsoft Alias: rimman

@karthiksubramanians Thank you for your inquiry. We are investigating and will update you upon confirmation of the correct response.

@karthiksubramanians Apologies for the delay on this inquiry. There is a single lease configuration and if the 3 prerequisites are met, that single lease configuration will dynamically scale to handle multiple monitored containers. The code sample provided GetChangeFeedProcessorBuilder handles this for you (again, assuming the prerequisites are met) resulting in the Change Feed Processor dynamically adjusting the load by redistributing the number of instances as they grow and shrink.

Moreover, the change feed processor can dynamically adjust to containers scale due to throughput or storage increases. When your container grows, the change feed processor transparently handles these scenarios by dynamically increasing the leases and distributing the new leases among existing instances.

We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


Issue with blank page execJS runtime error

Hi,
Any ideas on this. Currently when running it brings back the below details. I have tried using execjs 1.4 but this does not seem to make any difference. Currently using Ruby 1.9.3 on Windows.
localhost:3030
Try this: curl -d '{ "auth_token": "YOUR_AUTH_TOKEN", "text": "Hey, Look what I can do!" }' \http://localhost:3030/widgets/welcome
In the console output it mentions the below and no dashboard is viewable.
Details:
Uncaught Error: ExecJS::RuntimeError:
(in C:/Dashing/test2/assets/javascripts/application.coffee)

I did as @marcopelegrini suggest.

Install NodeJs
Install coofee-script : npm install -g coffee-script

Done!


Intalled, but won't open

Description
I've installed this for the first time, but it will not run.
Also, If I try to uninstall it, I get this error NSIS ERROR: Error launching installer
Error Log Attatched
1669192683350.log
DBeaver Version
22.2.25
Operating System
Windows 10
Database and driver
No response
Steps to reproduce
No response
Additional context
No response

Hi,
Could this be the only reason? Just asking as other members in my team have no problems using the App.
Anything to do with my Java? etc.

It doesn't seem like there's something wrong with your Java installation but with your Windows.
It has nothing to do with DBeaver, and we can't help, sorry.


Add a script to update the README table of supported languages and locales

Partial fix for #397.
Although sorted, the table contents are the same. Should the script be feeding additional languages and locales from sources other than dateparser.data.languages_info.language_locale_dict?

I like the idea, but I don't think adding such a big table of supported locales to the README has any sense, so I will keep this PR open until we finish this: https://github.com/scrapinghub/dateparser/issues/723 and then we can work on this, to see if we want to move that table to the docs or whatever.

Hi @Gallaecio!
This work would help a lot when updating the CLDR data: https://github.com/scrapinghub/dateparser/issues/826
The table was moved to the docs (supported_locales.rst). Could you update the code to work with it?
Regarding the source, I think it's OK to extract the language list from dateparser.data.languages_info.language_locale_dict. We could also get the list of supported locales from the modules in dateparser.data.date_translation_data, while the derived locales (locale + region) are in the locale_specific key, but I think that this is too tricky and it should be the same.


Add job to publish packages on PyPI when a tag passes tests

@daviddoji was using an older version, because the 2024.1 tag was not published to PyPI. This automates that step, so packages will be uploaded automatically for a tag, so long as it passes tests.
@philsmt @tmichela This also needs some config on PyPI to allow it to upload ('trusted publisher'). I don't seem to have enough access to set that up.

@philsmt @tmichela This also needs some config on PyPI to allow it to upload ('trusted publisher'). I don't seem to have enough access to set that up.

Same for me looks like only Philipp is owner

Thanks, I missed the on-push-tag thing.
I've copied what we already have for EXtra-data, which has been fine so far, but I don't mind making it more specific if we want. The on-push-tag filter uses glob patterns rather than regexes, though. And it doesn't look like there's a =~ operator, unless it's undocumented.

Fine then, LGTM

Philipp upgraded my access to the project on PyPI, so I've set it up there. With a bit of luck this should all work next time we make a tag.


Review all Diego options/properties

Review all properties in diego-release/jobs/*/spec and update accordingly.

Our current properties seem sane.


[6.8] [elasticsearch] remove unused sidecarResources value (#1185)

Backports the following commits to 6.8:

[elasticsearch] remove unused sidecarResources value (#1185)

waiting @elastic/es-delivery that this can be backported on 6.8 branch (https://github.com/elastic/helm-charts/pull/1183#issuecomment-839752102)

Closing this PR following https://github.com/elastic/helm-charts/pull/1213#issuecomment-849810325


Backporting nil values fixes from master to 6-0-0-stable

Arel 6.0.3
Post.arel_table[:title].lower.eq(nil).to_sql
LOWER("post"."title") = NULL
Arel 7:
Post.arel_table[:title].lower.eq(nil).to_sql
LOWER("post"."title") IS NULL
Cherry picking commits 0b720f7, ba5effd, and 0cd5fa9 seems to resolve it for me.  Would something like this get put onto Arel 6.x so it can work with Rails 4.x?

We just hit this problem as well in a Rails 4.x app. Would love to see this backported to a 6.0.x branch so we can avoid monkey-patching a fix in.

Could you open a PR with it? Thanks


[smoke] - add hipmalloc-omptarget-multifile

This tests the usage of the hip_host_overlay.h header in multiple files. There was an issue linking object files together causing duplicate symbols to clash when using hipMalloc + openmp target regions.

smoke is fine, I already merged a fix.


Expand to Support Whitelist(s)

It would be great if this script could also handle whitelists also. Additionally, if it could support the importing of the white and blacklist regex lists too, even better.
Thanks for a great script!

I think that'll do it with the 0.3.0 release  . I'm more than happy to add other maintained sources!


CAMEL-21472: try assign new traceId for exchanges without parent span

Description
See https://issues.apache.org/jira/browse/CAMEL-21472

I have gone through a bit more troubleshooting about this. I've added some logging traces and I am not able to reproduce the problem on Spring Boot runtime. Starting a simple timer to log seems to create a new span at each exchange with actual 4.9.0-SNAPSHOT code:
2024-11-27T13:22:20.859+01:00 DEBUG 446184 --- [ - timer://yaml] [69da4c773180c20d932deb3dbda91b50-a9710cbc4e5acb99] org.apache.camel.tracing.Tracer          : Tracing: start server span=OpenTelemetrySpanAdapter [baggage={}, span=PropagatedSpan{ImmutableSpanContext{traceId=69da4c773180c20d932deb3dbda91b50, spanId=a9710cbc4e5acb99, traceFlags=00, traceState=ArrayBasedTraceState{entries=[]}, remote=false, valid=true}}] with parent null
....
2024-11-27T13:22:50.841+01:00 DEBUG 446184 --- [ - timer://yaml] [af918b6f238227c77a401fbb6ed07dff-0306f19c52754b1b] org.apache.camel.tracing.Tracer          : Tracing: start server span=OpenTelemetrySpanAdapter [baggage={}, span=PropagatedSpan{ImmutableSpanContext{traceId=af918b6f238227c77a401fbb6ed07dff, spanId=0306f19c52754b1b, traceFlags=00, traceState=ArrayBasedTraceState{entries=[]}, remote=false, valid=true}}] with parent null

What I have verified is that on Camel Main runtime we don't have any propagation at all, which is something that would require some attention. On Spring Boot, there is some injection that make this to work. How are you running the application? I wonder if the way it is executed is influencing the final behavior.

@thomas-gantenbein-tga I have the feeling that this has been solved already in 4.9.0-SNAPSHOT. Would you mind testing your reproducer against this version? At least, the simple Spring Boot example I run, does not reproduce the problem you've faced.

BTW, the tests I'm doing are building the java application and run via java -jar myapp.jar.

@thomas-gantenbein-tga I have the feeling that this has been solved already in 4.9.0-SNAPSHOT. Would you mind testing your reproducer against this version? At least, the simple Spring Boot example I run, does not reproduce the problem you've faced.

Sure, will do. Currently building. Module 203 of about 500 something. I'll let you know when I've built and tested.

@squakez, I tried with 4.9.0-SNAPSHOT. I wouldn't say it's fixed, it's just ... different. My reproducer goes as follows:
 from("netty-http:http://<IP_ADDRESS>:12345")
            .routeId("netty")
            .log("in netty route")
            .to("direct:aSlowerRoute")
            .to("direct:aFasterRoute");

        from("timer:mytimer?period=5000&repeatCount=2&synchronous=true")
            .routeId("timer")
            .log("in timer route")
            .to("direct:aSlowerRoute")
            .to("direct:aFasterRoute");

        from("direct:aSlowerRoute")
            .log("in aSlowerRoute")
            .delay(simple("${random(50, 350)}"))
            .log("still in aSlowerRoute");

        from("direct:aFasterRoute")
            .log("in aFasterRoute")
            .delay(simple("${random(10, 70)}"))
            .log("still in aFasterRoute");

And here are the logs:
camel-springboot 4.8.1
Timer, fire 1
21:08:39.362 INFO  Camel (camel-1) thread #2 - timer://mytimer [eca8ede291f7aacb9515ff3dd74f2ab0,ac054cb2298eff68] timer - in timer route
21:08:39.372 INFO  Camel (camel-1) thread #2 - timer://mytimer [eca8ede291f7aacb9515ff3dd74f2ab0,f35a35101a900e77] route1 - in aSlowerRoute
21:08:39.598 INFO  Camel (camel-1) thread #3 - Delay [eca8ede291f7aacb9515ff3dd74f2ab0,916eba23ab488e92] route1 - still in aSlowerRoute
21:08:39.601 INFO  Camel (camel-1) thread #3 - Delay [eca8ede291f7aacb9515ff3dd74f2ab0,d3604be1184bfe9c] route2 - in aFasterRoute
21:08:39.657 INFO  Camel (camel-1) thread #4 - Delay [eca8ede291f7aacb9515ff3dd74f2ab0,0b938354295aa230] route2 - still in aFasterRoute

Timer, fire 2
❌ traceId from fire 1
✔ thread #3 gets spanId from fire 1
21:08:44.268 INFO  Camel (camel-1) thread #2 - timer://mytimer [eca8ede291f7aacb9515ff3dd74f2ab0,0ef83f6235ee1b8e] timer - in timer route
21:08:44.270 INFO  Camel (camel-1) thread #2 - timer://mytimer [eca8ede291f7aacb9515ff3dd74f2ab0,ddf8b1f376f4017b] route1 - in aSlowerRoute
21:08:44.456 INFO  Camel (camel-1) thread #3 - Delay [eca8ede291f7aacb9515ff3dd74f2ab0,d3604be1184bfe9c] route1 - still in aSlowerRoute
21:08:44.458 INFO  Camel (camel-1) thread #3 - Delay [eca8ede291f7aacb9515ff3dd74f2ab0,55e33e194dbad337] route2 - in aFasterRoute
21:08:44.472 INFO  Camel (camel-1) thread #4 - Delay [eca8ede291f7aacb9515ff3dd74f2ab0,ffc9bc53e60435b6] route2 - still in aFasterRoute

camel-springboot 4.9.0-SNAPSHOT
Timer, fire 1
❌ traceId and spanId not propagated to thread #3 and #4
20:51:23.689 INFO  Camel (camel-1) thread #2 - timer://mytimer [a92b2cd46ea975b5f2065cb98ca98b8a,2ddffed3056dba31] timer - in timer route
20:51:23.700 INFO  Camel (camel-1) thread #2 - timer://mytimer [a92b2cd46ea975b5f2065cb98ca98b8a,3cc7c4c0b12fffab] route1 - in aSlowerRoute
20:51:23.839 INFO  Camel (camel-1) thread #3 - Delay [,] route1 - still in aSlowerRoute
20:51:23.842 INFO  Camel (camel-1) thread #3 - Delay [a92b2cd46ea975b5f2065cb98ca98b8a,c5d45ed0f340e491] route2 - in aFasterRoute
20:51:23.876 INFO  Camel (camel-1) thread #4 - Delay [,] route2 - still in aFasterRoute

Timer, fire 2
✔ New traceId generated
❌ traceId and spanId not propagated to thread #4
❌ thread #3 gets traceId and spanId from fire 1 before getting correct traceId and new spanId
❌ thread #4 does not get a traceId
20:51:28.598 INFO  Camel (camel-1) thread #2 - timer://mytimer [4d8bdc9683b6968898cd479b8259170a,e247c14e0a6280af] timer - in timer route
20:51:28.600 INFO  Camel (camel-1) thread #2 - timer://mytimer [4d8bdc9683b6968898cd479b8259170a,0a160216be3f84e2] route1 - in aSlowerRoute
20:51:28.696 INFO  Camel (camel-1) thread #3 - Delay [a92b2cd46ea975b5f2065cb98ca98b8a,c5d45ed0f340e491] route1 - still in aSlowerRoute
20:51:28.698 INFO  Camel (camel-1) thread #3 - Delay [4d8bdc9683b6968898cd479b8259170a,6021d78f652666aa] route2 - in aFasterRoute
20:51:28.726 INFO  Camel (camel-1) thread #4 - Delay [,] route2 - still in aFasterRoute

curl, no traceparent header
✔ New traceId generated
✔ New traceId propagated to thread #4 and #8
❌ two times same spanId 18fa8a062cf5ce69
20:51:58.911 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [f42e6647e9cac76b870f4b91dd63869e,591e5965005b199f] netty - in netty route
20:51:58.913 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [f42e6647e9cac76b870f4b91dd63869e,cf69a2f758a9c90d] route1 - in aSlowerRoute
20:51:59.077 INFO  Camel (camel-1) thread #5 - Delay [f42e6647e9cac76b870f4b91dd63869e,18fa8a062cf5ce69] route1 - still in aSlowerRoute
20:51:59.079 INFO  Camel (camel-1) thread #5 - Delay [f42e6647e9cac76b870f4b91dd63869e,8d3c24f005b6e313] route2 - in aFasterRoute
20:51:59.100 INFO  Camel (camel-1) thread #6 - Delay [f42e6647e9cac76b870f4b91dd63869e,18fa8a062cf5ce69] route2 - still in aFasterRoute

curl, with traceparent header 4bf92f3577b34da6a3ce929d0e0e4739
✔ traceId taken from http header
✔ traceId propagated to thread #3 and #8
❌ thread #3 gets traceId and spanId from timer, fire 2
20:52:17.908 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,f30adaa693cc553c] netty - in netty route
20:52:17.909 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,8bb8773c982c307c] route1 - in aSlowerRoute
20:52:18.205 INFO  Camel (camel-1) thread #3 - Delay [4d8bdc9683b6968898cd479b8259170a,6021d78f652666aa] route1 - still in aSlowerRoute
20:52:18.207 INFO  Camel (camel-1) thread #3 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,b1885430d753d182] route2 - in aFasterRoute
20:52:18.255 INFO  Camel (camel-1) thread #4 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,3afe751f39b1a76f] route2 - still in aFasterRoute

curl, with traceparent header 4bf92f3577b34da6a3ce929d0e0e4740
✔ traceId taken from http header
❌ same spanId d916452083efcd5f
20:52:33.461 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,a15d1d4b16c0dcb0] netty - in netty route
20:52:33.463 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,19edc06dcd19a524] route1 - in aSlowerRoute
20:52:33.744 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,d916452083efcd5f] route1 - still in aSlowerRoute
20:52:33.745 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,71800a5a37af3c69] route2 - in aFasterRoute
20:52:33.779 INFO  Camel (camel-1) thread #10 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,d916452083efcd5f] route2 - still in aFasterRoute

curl, no traceparent header
✔ traceId taken from http header
❌ trace #5 gets traceId and spanId from curl, first call
20:52:53.253 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [8ea524d7af24a239376e3f9a2058dc34,5b967ade2153d3ea] netty - in netty route
20:52:53.254 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [8ea524d7af24a239376e3f9a2058dc34,3940e6071069658c] route1 - in aSlowerRoute
20:52:53.455 INFO  Camel (camel-1) thread #5 - Delay [f42e6647e9cac76b870f4b91dd63869e,8d3c24f005b6e313] route1 - still in aSlowerRoute
20:52:53.457 INFO  Camel (camel-1) thread #5 - Delay [8ea524d7af24a239376e3f9a2058dc34,5b7bbb88fc47ced8] route2 - in aFasterRoute
20:52:53.475 INFO  Camel (camel-1) thread #6 - Delay [8ea524d7af24a239376e3f9a2058dc34,c63588f5683b94e2] route2 - still in aFasterRoute

Thanks @thomas-gantenbein-tga I will go through these scenarios and try to figure it out what's wrong.

Thanks a lot @squakez.
By the way:

Context propagation is not trivial, and when done incorrectly can lead to broken traces or even mixed traces.
(from https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-context/latest/io/opentelemetry/context/Context.html)

Couldn't agree more 😄
I also tried this:

We provide a debug mechanism for context propagation, which can be enabled by setting -Dio.opentelemetry.context.enableStrictContext=true in your JVM args. This will enable a strict checker that makes sure that Scopes are closed on the correct thread and that they are not garbage collected before being closed.

I didn't observe that this changed the behaviour, though.

I did more troubleshooting but it is a complex thing to really understand. I think the changes in the PR are patching the problems you're facing by kind of resetting the trace at every exchange start. However it would not be fixing the root cause. I'm inclined to accept and merge this in order to get at least a quick patch in 4.9.0 and 4.8.2 which we should release soon, and in the while we need to continue the investigation and get a proper understanding of the propagation mechanism and how to finally fix it.
@oscerd @davsclaus wdyt?

I'd advocate to merge this.

Would you mind letting me run my samples again with these changes on top of 4.9.0-SNAPSHOT? I had only tried on top of 4.8.1, and I wasn't paranoid enough to also check spanIds and try with several curl calls. Just want to be sure that it's actually better at least for the scenarios I've tested, not just different.

Would you mind letting me run my samples again with these changes on top of 4.9.0-SNAPSHOT? I had only tried on top of 4.8.1, and I wasn't paranoid enough to also check spanIds and try with several curl calls. Just want to be sure that it's actually better at least for the scenarios I've tested, not just different.

Sure. We'll be waiting for your feedback anyway.

I've cherry-picked this commit on top of ff5caa5b999 and ran my reproducer. The result: No, let's not merge this.
Whatever was changed between ff5caa5b999 and release 4.8.1 fixed the issue of the same traceId being generated every time a consumer thread would start an exchange. Given this fix, my own "fix" on top of it even makes things slightly worse: Where I invoke the netty route without a traceparent header, thread #3 now gets a brand-new traceId, same for thread #6 in the last netty route:
21:08:33.366 INFO  Camel (camel-1) thread #2 - timer://mytimer [3e79d97fa497733fd51565e48c4bc79a,5caae76825597471] timer - in timer route
21:08:33.377 INFO  Camel (camel-1) thread #2 - timer://mytimer [3e79d97fa497733fd51565e48c4bc79a,0e35b3bee30a48d6] route1 - in aSlowerRoute
21:08:33.468 INFO  Camel (camel-1) thread #3 - Delay [,] route1 - still in aSlowerRoute
21:08:33.471 INFO  Camel (camel-1) thread #3 - Delay [3e79d97fa497733fd51565e48c4bc79a,95e1d7d8028296e0] route2 - in aFasterRoute
21:08:33.498 INFO  Camel (camel-1) thread #4 - Delay [,] route2 - still in aFasterRoute

21:08:38.255 INFO  Camel (camel-1) thread #2 - timer://mytimer [8a6688d4bff62bf0d1444ff0d9aaa210,d8457081e524cdcc] timer - in timer route
21:08:38.256 INFO  Camel (camel-1) thread #2 - timer://mytimer [8a6688d4bff62bf0d1444ff0d9aaa210,9d32d658a3986dfc] route1 - in aSlowerRoute
21:08:38.338 INFO  Camel (camel-1) thread #3 - Delay [3e79d97fa497733fd51565e48c4bc79a,95e1d7d8028296e0] route1 - still in aSlowerRoute
21:08:38.340 INFO  Camel (camel-1) thread #3 - Delay [8a6688d4bff62bf0d1444ff0d9aaa210,b77cf7ed75eb0941] route2 - in aFasterRoute
21:08:38.385 INFO  Camel (camel-1) thread #4 - Delay [,] route2 - still in aFasterRoute

21:08:57.929 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [35e0dec31ec26df1204f91caa8f95091,c0a1af17056cb737] netty - in netty route
21:08:57.930 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [35e0dec31ec26df1204f91caa8f95091,e5cb71ad5987aa99] route1 - in aSlowerRoute
21:08:58.062 INFO  Camel (camel-1) thread #5 - Delay [a794c504464d2e41a73370554b431788,d4afe0b75c1c773b] route1 - still in aSlowerRoute
21:08:58.064 INFO  Camel (camel-1) thread #5 - Delay [35e0dec31ec26df1204f91caa8f95091,3cae953a6f3821e4] route2 - in aFasterRoute
21:08:58.097 INFO  Camel (camel-1) thread #6 - Delay [a794c504464d2e41a73370554b431788,d4afe0b75c1c773b] route2 - still in aFasterRoute

21:08:58.146 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,9bcb9c18fe6b3547] netty - in netty route
21:08:58.148 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,6504a15fc75cc4f7] route1 - in aSlowerRoute
21:08:58.482 INFO  Camel (camel-1) thread #3 - Delay [8a6688d4bff62bf0d1444ff0d9aaa210,b77cf7ed75eb0941] route1 - still in aSlowerRoute
21:08:58.483 INFO  Camel (camel-1) thread #3 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,711f994843db5d13] route2 - in aFasterRoute
21:08:58.500 INFO  Camel (camel-1) thread #4 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,1219ea22da276463] route2 - still in aFasterRoute

21:08:58.519 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,93029888ed44c3e3] netty - in netty route
21:08:58.520 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,ee5d491873836fc4] route1 - in aSlowerRoute
21:08:58.719 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,ca1e85b164b97e35] route1 - still in aSlowerRoute
21:08:58.721 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,3a6a7afc4d2f88e7] route2 - in aFasterRoute
21:08:58.755 INFO  Camel (camel-1) thread #10 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,ca1e85b164b97e35] route2 - still in aFasterRoute

21:08:58.774 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [8ab99ef0b2fbce66d11f747a1daf8f0c,f2baf5fab0ec1e7e] netty - in netty route
21:08:58.775 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [8ab99ef0b2fbce66d11f747a1daf8f0c,e5e2fa3ad6919297] route1 - in aSlowerRoute
21:08:59.031 INFO  Camel (camel-1) thread #5 - Delay [35e0dec31ec26df1204f91caa8f95091,3cae953a6f3821e4] route1 - still in aSlowerRoute
21:08:59.032 INFO  Camel (camel-1) thread #5 - Delay [8ab99ef0b2fbce66d11f747a1daf8f0c,0e548f6037c7f4d8] route2 - in aFasterRoute
21:08:59.088 INFO  Camel (camel-1) thread #6 - Delay [adb9fa707818304e40ec044a8a17bf93,037fa960a43b9ab2] route2 - still in aFasterRoute

Cherry-picking this commit on top of 4.8.1 gives me the logs below. Slightly better, by the looks of it, than 4.9.0-SNAPSHOT (ff5caa5), but still thread #3 in timer fire 2 gets traceId from timer fire 1, traceId c76b3ea6c032276dce25c4b9cbe5ae4e, spanId 477aa6e18490d3af figures two times on thread #5 ... so still not really working, not even as a quick workaround.
I tried this to see how my "quick fix" compares to the state of ff5caa5. Now I see this, I don't think it's worth finding out what changed between 4.9.0-SNAPHSOT (ff5caa5) and 4.8.1 and apply this quick-"fix" instead of whatever fix was introduced so far.
So I'll close this PR. Thanks for your comments and welcoming attitude, and sorry I couldn't help more.
21:33:28.772 INFO  Camel (camel-1) thread #2 - timer://mytimer [5317aa821834beaf211569b8fb5b817e,6ef9c33d89c30294] timer - in timer route
21:33:28.783 INFO  Camel (camel-1) thread #2 - timer://mytimer [5317aa821834beaf211569b8fb5b817e,0e99673bbeff9725] route1 - in aSlowerRoute
21:33:28.858 INFO  Camel (camel-1) thread #3 - Delay [5317aa821834beaf211569b8fb5b817e,25bc89ad835a23a6] route1 - still in aSlowerRoute
21:33:28.861 INFO  Camel (camel-1) thread #3 - Delay [5317aa821834beaf211569b8fb5b817e,b7f8defe3417006a] route2 - in aFasterRoute
21:33:28.931 INFO  Camel (camel-1) thread #4 - Delay [5317aa821834beaf211569b8fb5b817e,f845fc43adc2ca68] route2 - still in aFasterRoute

21:33:33.670 INFO  Camel (camel-1) thread #2 - timer://mytimer [78181387cecceb3da5915017c73738a7,a6ee4a4a472d6d4d] timer - in timer route
21:33:33.672 INFO  Camel (camel-1) thread #2 - timer://mytimer [78181387cecceb3da5915017c73738a7,9555f8aae3c71a91] route1 - in aSlowerRoute
21:33:33.736 INFO  Camel (camel-1) thread #3 - Delay [5317aa821834beaf211569b8fb5b817e,b7f8defe3417006a] route1 - still in aSlowerRoute
21:33:33.737 INFO  Camel (camel-1) thread #3 - Delay [78181387cecceb3da5915017c73738a7,8c095a8c44fd91cd] route2 - in aFasterRoute
21:33:33.752 INFO  Camel (camel-1) thread #4 - Delay [78181387cecceb3da5915017c73738a7,a1eb1b989c93a073] route2 - still in aFasterRoute

21:33:39.517 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [c76b3ea6c032276dce25c4b9cbe5ae4e,ad91c1c0287852de] netty - in netty route
21:33:39.518 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [c76b3ea6c032276dce25c4b9cbe5ae4e,a65fa72a4a4f2b3e] route1 - in aSlowerRoute
21:33:39.604 INFO  Camel (camel-1) thread #5 - Delay [c76b3ea6c032276dce25c4b9cbe5ae4e,0c408b291b1ac62e] route1 - still in aSlowerRoute
21:33:39.606 INFO  Camel (camel-1) thread #5 - Delay [c76b3ea6c032276dce25c4b9cbe5ae4e,477aa6e18490d3af] route2 - in aFasterRoute
21:33:39.621 INFO  Camel (camel-1) thread #6 - Delay [c76b3ea6c032276dce25c4b9cbe5ae4e,90434ec70f7877f7] route2 - still in aFasterRoute

21:33:39.687 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,2d577a9eb50864dc] netty - in netty route
21:33:39.688 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,ef865d37dbc382c7] route1 - in aSlowerRoute
21:33:39.808 INFO  Camel (camel-1) thread #3 - Delay [78181387cecceb3da5915017c73738a7,8c095a8c44fd91cd] route1 - still in aSlowerRoute
21:33:39.810 INFO  Camel (camel-1) thread #3 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,f24e260e1a00d437] route2 - in aFasterRoute
21:33:39.871 INFO  Camel (camel-1) thread #4 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,467e9f696896dbc7] route2 - still in aFasterRoute

21:33:39.905 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,bde97a94210de433] netty - in netty route
21:33:39.906 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,5aec4314c18bfdc8] route1 - in aSlowerRoute
21:33:39.972 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,1eed86ac5e7ce989] route1 - still in aSlowerRoute
21:33:39.974 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,f768efe1f4bd8cff] route2 - in aFasterRoute
21:33:39.991 INFO  Camel (camel-1) thread #10 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,b287662cf3806cdd] route2 - still in aFasterRoute

21:33:40.013 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [aaee8bcea728cf9ef2543c58509a70b6,9d144769d5605db8] netty - in netty route
21:33:40.014 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [aaee8bcea728cf9ef2543c58509a70b6,2a156c01c5a0857e] route1 - in aSlowerRoute
21:33:40.354 INFO  Camel (camel-1) thread #5 - Delay [c76b3ea6c032276dce25c4b9cbe5ae4e,477aa6e18490d3af] route1 - still in aSlowerRoute
21:33:40.356 INFO  Camel (camel-1) thread #5 - Delay [aaee8bcea728cf9ef2543c58509a70b6,29c3943b16347639] route2 - in aFasterRoute
21:33:40.414 INFO  Camel (camel-1) thread #6 - Delay [aaee8bcea728cf9ef2543c58509a70b6,7590460d39ed1fdd] route2 - still in aFasterRoute

Thanks a lot for informing us. I'll continue the investigation and hopefully we can have a fix within 4.10 release.

@squakez, one more thing: When using the option camel.opentelemetry.traceProcessors = true, the whole thing works better (logs below). Though at startup, I get warnings like this: 08:14:45.382 WARN  main [,] o.a.camel.impl.engine.DefaultChannel - Interceptor: org.apache.camel.opentelemetry.OpenTelemetryTracingStrategy@339cedbb at: To[direct:aFasterRoute] does not return an AsyncProcessor instance. This causes the asynchronous routing engine to not work as optimal as possible. See more details at the InterceptStrategy javadoc. Camel will use a bridge to adapt the interceptor to the asynchronous routing engine, but its not the most optimal solution. Please consider changing your interceptor to comply.
`
08:14:47.336 INFO  Camel (camel-1) thread #2 - timer://mytimer [d9dc304941ef6510bc5565b8f254a850,3b8c99e69e89ac46] timer - in timer route
08:14:47.347 INFO  Camel (camel-1) thread #2 - timer://mytimer [d9dc304941ef6510bc5565b8f254a850,3e83038ad51081c4] route1 - in aSlowerRoute
08:14:47.436 INFO  Camel (camel-1) thread #2 - timer://mytimer [d9dc304941ef6510bc5565b8f254a850,483ec28803781cbb] route1 - still in aSlowerRoute
08:14:47.440 INFO  Camel (camel-1) thread #2 - timer://mytimer [d9dc304941ef6510bc5565b8f254a850,f1f8a8ec5bb5194d] route2 - in aFasterRoute
08:14:47.469 INFO  Camel (camel-1) thread #2 - timer://mytimer [d9dc304941ef6510bc5565b8f254a850,5dbcb616875503a7] route2 - still in aFasterRoute

08:14:52.228 INFO  Camel (camel-1) thread #2 - timer://mytimer [fc320b7df9f7c59f2c98745ab760a457,68bbbdc5c2b5b3b2] timer - in timer route
08:14:52.229 INFO  Camel (camel-1) thread #2 - timer://mytimer [fc320b7df9f7c59f2c98745ab760a457,2b54666cbe277553] route1 - in aSlowerRoute
08:14:52.404 INFO  Camel (camel-1) thread #2 - timer://mytimer [fc320b7df9f7c59f2c98745ab760a457,9c09f771b3986b17] route1 - still in aSlowerRoute
08:14:52.406 INFO  Camel (camel-1) thread #2 - timer://mytimer [fc320b7df9f7c59f2c98745ab760a457,3017c9411447ac44] route2 - in aFasterRoute
08:14:52.457 INFO  Camel (camel-1) thread #2 - timer://mytimer [fc320b7df9f7c59f2c98745ab760a457,bafe17471b587c8f] route2 - still in aFasterRoute

08:15:05.296 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [89d9acf8c4f890ac81fe2aab0bce2002,a16898568c48c78d] netty - in netty route
08:15:05.297 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [89d9acf8c4f890ac81fe2aab0bce2002,84ad1887adbc74db] route1 - in aSlowerRoute
08:15:05.524 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [89d9acf8c4f890ac81fe2aab0bce2002,e6d220ca958a4f9a] route1 - still in aSlowerRoute
08:15:05.526 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [89d9acf8c4f890ac81fe2aab0bce2002,ea825b6be46cfe15] route2 - in aFasterRoute
08:15:05.555 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [89d9acf8c4f890ac81fe2aab0bce2002,2d9057f519b5e2db] route2 - still in aFasterRoute

08:15:05.614 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,adabb6a53e513883] netty - in netty route
08:15:05.615 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,ae6c71463b133f2d] route1 - in aSlowerRoute
08:15:05.687 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,fd1545f6e746681d] route1 - still in aSlowerRoute
08:15:05.689 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,2861a768e255f9ba] route2 - in aFasterRoute
08:15:05.710 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,b6ea92a8423be3e5] route2 - still in aFasterRoute

08:15:05.741 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,d13dd0d0403eabbe] netty - in netty route
08:15:05.742 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,9b2568376d3cd991] route1 - in aSlowerRoute
08:15:05.952 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,6824ac16b7c78fe1] route1 - still in aSlowerRoute
08:15:05.953 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,a91fa67528c090e0] route2 - in aFasterRoute
08:15:05.979 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,e8b3647543f4c218] route2 - still in aFasterRoute

08:15:06.012 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [e8ef703f008340510601a72729d400fc,6171ea4d64c88c7e] netty - in netty route
08:15:06.013 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [e8ef703f008340510601a72729d400fc,9ca1ae64fe0435da] route1 - in aSlowerRoute
08:15:06.210 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [e8ef703f008340510601a72729d400fc,5669e77a4bf682ec] route1 - still in aSlowerRoute
08:15:06.213 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [e8ef703f008340510601a72729d400fc,6c5d8b45799e1c33] route2 - in aFasterRoute
08:15:06.236 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [e8ef703f008340510601a72729d400fc,0dfd964a17af815b] route2 - still in aFasterRoute

Thanks @thomas-gantenbein-tga . Yes, in that case we are creating a new span for each processor as well, so, likely the scope is not closed ahead of time. I still need to figure it out the entire propagation mechanism as it seems to be incomplete and broken somewhere in the camel-tracing component.

Just in case you decide not to remove MDC logging altogether: I think this could work now, @squakez. At least for logs from the log EIP or log component. For logs from Java code ... hm, well, that would still be shaky.
I tried with the same route as above, that is:
        from("netty-http:http://<IP_ADDRESS>:12345")
            .routeId("netty")
            .log("in netty route")
            .to("direct:aSlowerRoute")
            .to("direct:aFasterRoute");

        from("timer:mytimer?period=5000&repeatCount=2&synchronous=true")
            .routeId("timer")
            .log("in timer route")
            .to("direct:aSlowerRoute")
            .to("direct:aFasterRoute");

        from("direct:aSlowerRoute")
            .log("in aSlowerRoute")
            .delay(simple("${random(50, 350)}"))
            .log("still in aSlowerRoute");

        from("direct:aFasterRoute")
            .log("in aFasterRoute")
            .delay(simple("${random(10, 70)}"))
            .log("still in aFasterRoute");

Waited for the timer to fire two times, then curl localhost:12345 && curl -H "traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4739-00f067aa0ba902b7-01" localhost:12345 && curl -H "traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4740-00f067aa0ba902b7-01" localhost:12345 && curl localhost:12345
Logs:
20:12:44.994 INFO  Camel (camel-1) thread #2 - timer://mytimer [d7d91e81efc3acf4e0730bee88601e7c,6e1c0a64a2feec44] timer - in timer route
20:12:45.015 INFO  Camel (camel-1) thread #2 - timer://mytimer [d7d91e81efc3acf4e0730bee88601e7c,1be08f81939abccc] route1 - in aSlowerRoute
20:12:45.335 INFO  Camel (camel-1) thread #3 - Delay [d7d91e81efc3acf4e0730bee88601e7c,1be08f81939abccc] route1 - still in aSlowerRoute
20:12:45.339 INFO  Camel (camel-1) thread #3 - Delay [d7d91e81efc3acf4e0730bee88601e7c,46d1457be03f7ada] route2 - in aFasterRoute
20:12:45.397 INFO  Camel (camel-1) thread #4 - Delay [d7d91e81efc3acf4e0730bee88601e7c,46d1457be03f7ada] route2 - still in aFasterRoute

20:12:49.868 INFO  Camel (camel-1) thread #2 - timer://mytimer [ef249c428653959d02560131d975b206,9141be8a7b20d5a5] timer - in timer route
20:12:49.869 INFO  Camel (camel-1) thread #2 - timer://mytimer [ef249c428653959d02560131d975b206,0fae7d3d4de2631c] route1 - in aSlowerRoute
20:12:49.983 INFO  Camel (camel-1) thread #3 - Delay [ef249c428653959d02560131d975b206,0fae7d3d4de2631c] route1 - still in aSlowerRoute
20:12:49.984 INFO  Camel (camel-1) thread #3 - Delay [ef249c428653959d02560131d975b206,72e273fc1ff50c5a] route2 - in aFasterRoute
20:12:50.028 INFO  Camel (camel-1) thread #4 - Delay [ef249c428653959d02560131d975b206,72e273fc1ff50c5a] route2 - still in aFasterRoute

20:13:17.016 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [86aeeb0e2cb978b7b376430045338db5,283b751c9e8bd65e] netty - in netty route
20:13:17.017 INFO  Camel (camel-1) thread #8 - NettyConsumerExecutorGroup [86aeeb0e2cb978b7b376430045338db5,2747fb1cca26d6dd] route1 - in aSlowerRoute
20:13:17.079 INFO  Camel (camel-1) thread #5 - Delay [86aeeb0e2cb978b7b376430045338db5,2747fb1cca26d6dd] route1 - still in aSlowerRoute
20:13:17.081 INFO  Camel (camel-1) thread #5 - Delay [86aeeb0e2cb978b7b376430045338db5,639427d08d593827] route2 - in aFasterRoute
20:13:17.123 INFO  Camel (camel-1) thread #6 - Delay [86aeeb0e2cb978b7b376430045338db5,639427d08d593827] route2 - still in aFasterRoute

20:13:17.173 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,df985068b674f995] netty - in netty route
20:13:17.174 INFO  Camel (camel-1) thread #12 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4739,e06755720e1692de] route1 - in aSlowerRoute
20:13:17.351 INFO  Camel (camel-1) thread #3 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,e06755720e1692de] route1 - still in aSlowerRoute
20:13:17.353 INFO  Camel (camel-1) thread #3 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,08f9b17fe5fbee60] route2 - in aFasterRoute
20:13:17.408 INFO  Camel (camel-1) thread #4 - Delay [4bf92f3577b34da6a3ce929d0e0e4739,08f9b17fe5fbee60] route2 - still in aFasterRoute

20:13:17.429 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,5c9ba31a6a70e867] netty - in netty route
20:13:17.430 INFO  Camel (camel-1) thread #16 - NettyConsumerExecutorGroup [4bf92f3577b34da6a3ce929d0e0e4740,7eed5ecec22b3281] route1 - in aSlowerRoute
20:13:17.689 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,7eed5ecec22b3281] route1 - still in aSlowerRoute
20:13:17.690 INFO  Camel (camel-1) thread #9 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,9920ef6a743629a7] route2 - in aFasterRoute
20:13:17.720 INFO  Camel (camel-1) thread #10 - Delay [4bf92f3577b34da6a3ce929d0e0e4740,9920ef6a743629a7] route2 - still in aFasterRoute

20:13:17.741 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [8f1095f44448c6632ba4e97597a2ce5a,66661fb8786cf397] netty - in netty route
20:13:17.742 INFO  Camel (camel-1) thread #20 - NettyConsumerExecutorGroup [8f1095f44448c6632ba4e97597a2ce5a,3b42be0fae97dd0e] route1 - in aSlowerRoute
20:13:17.799 INFO  Camel (camel-1) thread #5 - Delay [8f1095f44448c6632ba4e97597a2ce5a,3b42be0fae97dd0e] route1 - still in aSlowerRoute
20:13:17.800 INFO  Camel (camel-1) thread #5 - Delay [8f1095f44448c6632ba4e97597a2ce5a,e5fc8dae051fc33e] route2 - in aFasterRoute
20:13:17.839 INFO  Camel (camel-1) thread #6 - Delay [8f1095f44448c6632ba4e97597a2ce5a,e5fc8dae051fc33e] route2 - still in aFasterRoute

@squakez, what do you think: Let's close this PR, since you are working on solving the root problem of this? And maybe decline CAMEL-21472 since what I reported turned out to be more of a symptom than a problem, and I guess your upcoming contribution has a much wider scope than that JIRA?

@thomas-gantenbein-tga yes, we can close this PR. Actually we should not close the Jira issue though, as indeed there is a problem how the tracing component works. Fortunately there are patches in place that makes the tracing working correctly when pushing traces to the collector, but, does not work when we use the MDC, hiding some flaw in the design. I am working on it since a couple of weeks and I am getting a deeper knowledge of the entire stack. We have a coupling beetween the tracing component (which should be completely generic and abstract) and the opentelemetry that makes the entire stack a bit inconsistent. I have the feeling we need to go through a deep refactoring as any further patch is solving some problem but potentially opening others (ie, I solved the MDC problem but there is some span leaking I am not able to figure it out). I'll provide more updates as soon as the analysis is progressing.


Helm 2: Tiller deployment spec via helm init uses deprecated api for Kubernetes 1.16

Output of helm version:
$ helm version --client
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-beta.2", GitCommit:"48ca054daba9e610f13c6d6bfcedf6c7de12b138", GitTreeState:"clean", BuildDate:"2019-09-04T15:52:50Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-alpha.3", GitCommit:"28e88e3f19c37242db1a456b1f45c543c4a540fe", GitTreeState:"clean", BuildDate:"2019-08-07T16:08:39Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):  AKS
Seeing the following error
$ helm init --service-account tiller
$HELM_HOME has been configured at /Users/${USER}/.helm.
Error: error installing: the server could not find the requested resource

Upon closer inspection. This API is deprecated in 1.16 as per - https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/
$ helm init --service-account tiller --debug
---
apiVersion: extensions/v1beta1

Solution is to bump to apps/v1 of deployment

Looks like there are other spec changes needed too
error: error validating "STDIN": error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec; if you choose to ignore these errors, turn validation off with --validate=false

The addition of the spec.selector seemed to at least get it to install
<snip>
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
<snip>

duplicate of https://github.com/helm/helm/issues/6374. Thanks!

输出修改api和selector,或者换更新的版本


SwayFmt: Allow alignment of struct/enum field/variant types

This is purely preference, but I much prefer enums/structs to be formatted like this:
enum InventoryEvent {
    CustomerPurchase : Receipt,
    ItemLoss         : Claim,
    CustomerReturn   : Refund,
}

rather than the Rust default which doesn’t align things. I find this much more readable. Would this be easy to implement, perhaps configurably (and as the default)?

If configurable, then depends on https://github.com/FuelLabs/sway/issues/605

If configurable, then depends on #605

We can make it configurable, but I think the intention was to make it the standard. Correct me if I'm wrong @sezna ?

I went ahead and added you as well @adlerjohn . Currently awaiting amendments from Alex to what I already have, which you can find here

If configurable, then depends on #605

We can make it configurable, but I think the intention was to make it the standard. Correct me if I'm wrong @sezna ?

The idea is to make it configurable, but the default. We could implement it with a basic toggle boolean for now and hook it up to the toml when that becomes available.

Would this be easy to implement, perhaps configurably (and as the default) [...]

I would recommend we first review and accept #622
after that @eureka-cpu can try to tackle this one.
For configuration, we can have a Config Struct passed to the formatter,
currently the tab size is the only parameter that is passed there so we can create something like this
struct FmtConfig {
   tab_size,
   format_enums_acorrding_to_alex,
   ...

The general opinion from #677 seems to be that this diverges from Rust, and so it would be very opinionated (in a bad way) to have.


INVALID_ARGUMENT thrown by subscript during simplified path execution mode

Description
INVALID_ARGUMENT thrown by subscript during simplified path execution mode.
Error Reproduction
velox_expressionVerifier_kt4TFY.zip
Relevant logs
I0103 20:02:23.647855 152733 ExpressionFuzzer.cpp:798] ==============================> Started iteration 2615 (seed:<PHONE_NUMBER>)
I0103 20:02:23.653506 152733 ExpressionVerifier.cpp:80] Executing expression: array_position(10 elements starting at 0 {2009-12-12T09:31:54.894841300, 1995-06-02T13:30:43.913646693, 1987-11-24T15:15:05.236538757, null, 1971-01-11T15:43:18.577269835, ...},"c0",bitwise_left_shift(divide("c1",subscript(slice(array_constructor(abs(subscript(null,subscript("c2",1178731994)))),"c3",8565660703275138108),bitwise_right_shift_arithmetic("c4",105514524058872182))),mod(array_min(slice(array_constructor(round(94),subscript(map_values(1 elements starting at 100 {1204953800 => 124}),bitwise_not(subscript(map_concat(null,"c5",10 elements starting at 20 {6383568212542281926 => [20->37] [37->28] null,<PHONE_NUMBER>907749929 => [21->144] [144->111] 61,<PHONE_NUMBER>823304865 => [22->35] [35->103] 64,<PHONE_NUMBER>157614835 => [23->97] [97->7] 50,<PHONE_NUMBER>026389917 => [24->48] [48->111] 61, ...},10 elements starting at 640 {3652459724368932121 => 29,<PHONE_NUMBER>570921515 => 29,<PHONE_NUMBER>656983556 => 29,<PHONE_NUMBER>288938825 => 29,<PHONE_NUMBER>431640803 => 29, ...},"c6","c7",10 elements starting at 500 {6100305555218967284 => [500->778] [778->268] [268->617] 47,<PHONE_NUMBER>154443245 => [501->733] [733->519] [519->180] 47,<PHONE_NUMBER>055991992 => [502->363] [363->476] [476->628] 47,<PHONE_NUMBER>69288971 => [503->407] [407->280] null,<PHONE_NUMBER>774667931 => [504->163] [163->34] [34->589] 47, ...}),3297020222291298957))),array_max(array_distinct("c8"))),bitwise_xor(mod(subscript(array_except("c8",slice("c8",147037367031698285,1543488174578509901)),array_position(10 elements starting at 120 {[120->102]<PHONE_NUMBER>762476639, [121->114]<PHONE_NUMBER>485361845, [122->94]<PHONE_NUMBER>252441841, [123->40]<PHONE_NUMBER>573319806, [124->88]<PHONE_NUMBER>040015408, ...},833651070002152173,array_position(10 elements starting at 70 {[70->156] [156->89]<PHONE_NUMBER>710933014, [71->94] [94->105]<PHONE_NUMBER>418322431, [72->94] [94->105]<PHONE_NUMBER>418322431, null, [74->157] null, ...},4418456305701289008,"c3"))),abs(round(round(108,"c9"),ceiling("c9")))),round(108,"c9")),2792615629279082903)),round(108,"c9"))))
I0103 20:02:23.653666 152733 ExpressionVerifier.cpp:32] 10 vectors as input:
I0103 20:02:23.653676 152733 ExpressionVerifier.cpp:34] 	[CONSTANT TIMESTAMP: 100 elements, 2008-04-23T07:34:35.357243854]
I0103 20:02:23.653687 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY TINYINT: 100 elements, 9 nulls], [CONSTANT TINYINT: 100 elements, 115]
I0103 20:02:23.653697 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY ARRAY<INTEGER>: 100 elements, 9 nulls], [ARRAY ARRAY<INTEGER>: 100 elements, no nulls]
I0103 20:02:23.653705 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY BIGINT: 100 elements, 11 nulls], [DICTIONARY BIGINT: 100 elements, 7 nulls], [CONSTANT BIGINT: 100 elements,<PHONE_NUMBER>360127345]
I0103 20:02:23.653717 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY BIGINT: 100 elements, 8 nulls], [FLAT BIGINT: 100 elements, 12 nulls]
I0103 20:02:23.653724 152733 ExpressionVerifier.cpp:34] 	[MAP MAP<BIGINT,TINYINT>: 100 elements, no nulls]
I0103 20:02:23.653731 152733 ExpressionVerifier.cpp:34] 	[CONSTANT MAP<BIGINT,TINYINT>: 100 elements, 10 elements starting at 10 {7058905778023661630 => null,<PHONE_NUMBER>567541940 => [11->10] null,<PHONE_NUMBER>787841446 => [12->0] null,<PHONE_NUMBER>931326294 => [13->4] 125,<PHONE_NUMBER>268200636 => [14->15] 40, ...}], [MAP MAP<BIGINT,TINYINT>: 2 elements, no nulls]
I0103 20:02:23.653753 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY MAP<BIGINT,TINYINT>: 100 elements, 13 nulls], [MAP MAP<BIGINT,TINYINT>: 100 elements, no nulls]
I0103 20:02:23.653760 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY ARRAY<TINYINT>: 100 elements, 15 nulls], [ARRAY ARRAY<TINYINT>: 100 elements, no nulls]
I0103 20:02:23.653769 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY INTEGER: 100 elements, 8 nulls], [DICTIONARY INTEGER: 100 elements, 12 nulls], [DICTIONARY INTEGER: 100 elements, 9 nulls], [CONSTANT INTEGER: 100 elements,<PHONE_NUMBER>]
I0103 20:02:23.658988 152733 ExpressionVerifier.cpp:133] Modified inputs for common eval path:
I0103 20:02:23.659003 152733 ExpressionVerifier.cpp:32] 10 vectors as input:
I0103 20:02:23.659006 152733 ExpressionVerifier.cpp:34] 	[LAZY TIMESTAMP: 100 elements, no nulls]
I0103 20:02:23.659015 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY TINYINT: 100 elements, 9 nulls], [CONSTANT TINYINT: 100 elements, 115]
I0103 20:02:23.659026 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY ARRAY<INTEGER>: 100 elements, 9 nulls], [ARRAY ARRAY<INTEGER>: 100 elements, no nulls]
I0103 20:02:23.659035 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY BIGINT: 100 elements, 11 nulls], [DICTIONARY BIGINT: 100 elements, 7 nulls], [CONSTANT BIGINT: 100 elements,<PHONE_NUMBER>360127345]
I0103 20:02:23.659047 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY BIGINT: 100 elements, 8 nulls], [FLAT BIGINT: 100 elements, 12 nulls]
I0103 20:02:23.659055 152733 ExpressionVerifier.cpp:34] 	[MAP MAP<BIGINT,TINYINT>: 100 elements, no nulls]
I0103 20:02:23.659062 152733 ExpressionVerifier.cpp:34] 	[CONSTANT MAP<BIGINT,TINYINT>: 100 elements, 10 elements starting at 10 {7058905778023661630 => null,<PHONE_NUMBER>567541940 => [11->10] null,<PHONE_NUMBER>787841446 => [12->0] null,<PHONE_NUMBER>931326294 => [13->4] 125,<PHONE_NUMBER>268200636 => [14->15] 40, ...}], [MAP MAP<BIGINT,TINYINT>: 2 elements, no nulls]
I0103 20:02:23.659087 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY MAP<BIGINT,TINYINT>: 100 elements, 13 nulls], [MAP MAP<BIGINT,TINYINT>: 100 elements, no nulls]
I0103 20:02:23.659096 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY ARRAY<TINYINT>: 100 elements, 15 nulls], [ARRAY ARRAY<TINYINT>: 100 elements, no nulls]
I0103 20:02:23.659104 152733 ExpressionVerifier.cpp:34] 	[DICTIONARY INTEGER: 100 elements, 8 nulls], [DICTIONARY INTEGER: 100 elements, 12 nulls], [DICTIONARY INTEGER: 100 elements, 9 nulls], [CONSTANT INTEGER: 100 elements,<PHONE_NUMBER>]
E0103 20:02:23.662540 152733 Exceptions.h:68] Line: ../.././velox/functions/lib/SubscriptUtil.h:227, Function:adjustIndex, Expression:  SQL array indices start at 1, Source: USER, ErrorCode: INVALID_ARGUMENT
E0103 20:02:23.662698 152733 FuzzerToolkit.cpp:131] Only simplified path threw exception:
I0103 20:02:23.663442 152733 ExpressionVerifier.cpp:295] Persisted input: --fuzzer_repro_path /tmp/fuzzer_repro/velox_expressionVerifier_kt4TFY --input_path /tmp/fuzzer_repro/velox_expressionVerifier_kt4TFY/input_vector --result_path /tmp/fuzzer_repro/velox_expressionVerifier_kt4TFY/result_vector --sql_path /tmp/fuzzer_repro/velox_expressionVerifier_kt4TFY/sql --lazy_column_list_path /tmp/fuzzer_repro/velox_expressionVerifier_kt4TFY/indices_of_lazy_columns --complex_constant_path /tmp/fuzzer_repro/velox_expressionVerifier_kt4TFY/complex_constants
terminate called after throwing an instance of 'facebook::velox::VeloxUserError'
  what():  Exception: VeloxUserError
Error Source: USER
Error Code: INVALID_ARGUMENT
Reason: SQL array indices start at 1
Retriable: False
Function: adjustIndex
File: ../.././velox/functions/lib/SubscriptUtil.h
Line: 227
Stack trace:
Stack trace has been disabled.Use --velox_exception_user_stacktrace=true to enable it.

I wonder if this is due to simplified path not doing constant folding. In this case that would be a bug in the Fuzzer itself, not a problem in subscript function.

Root cause: The issue here is that #3284 added a behavior change to subscript operator that if an array is empty then any subscript access (regardless of value) returns NULL. This happens because the code returns a null vector as soon as it confirms that the underlying values vector is of size zero which skips the checks for valid index values. However, it does not check the individual sizes of each array in the array vector. Therefore, if the underlying values vector is not a zero size vector but each individual array size is zero it would continue and encounter the part that checks for valid index values and eventually throw.
This is what happened in this issue, that the simplified path returned an arrayVector with non-empty values vector whereas the common path returned one with an empty values vector.
I then tried out this behavior in Presto and noticed that an error is always returned if the index is invalid, even if the input array is empty. So ideally, this should be the expected behavior and the fix here should be to ensure both common and simplified paths throw these user errors.
However, I noticed that another change #3509 further fortified the behavior (contrary to Presto's behavior) introduced in #3284 . Therefore, before I went ahead and made the change to conform with Presto, I wanted to confirm with others in the community.
cc @mbasmanova @kagamiori @kevinwilfong

@bikramSingh91 Bikram, thank you for investigating. We need to make sure the behavior matches Presto.

Root cause: The issue here is that #3284 added a behavior change to subscript operator that if an array is empty then any subscript access (regardless of value) returns NULL. This happens because the code returns a null vector as soon as it confirms that the underlying values vector is of size zero which skips the checks for valid index values. However, it does not check the individual sizes of each array in the array vector. Therefore, if the underlying values vector is not a zero size vector but each individual array size is zero it would continue and encounter the part that checks for valid index values and eventually throw.
This is what happened in this issue, that the simplified path returned an arrayVector with non-empty values vector whereas the common path returned one with an empty values vector.
I then tried out this behavior in Presto and noticed that an error is always returned if the index is invalid, even if the input array is empty. So ideally, this should be the expected behavior and the fix here should be to ensure both common and simplified paths throw these user errors.
However, I noticed that another change #3509 further fortified the behavior (contrary to Presto's behavior) introduced in #3284 . Therefore, before I went ahead and made the change to conform with Presto, I wanted to confirm with others in the community.
cc @mbasmanova @kagamiori @kevinwilfong

Hi @bikramSingh91, Thank you for looking into this issue. I'm trying to understand which part of #3284 is different from Presto. I did checked the query "select element_at(array[], 1)" in Presto and it returns NULL. So if the underlying element vector is empty, then we should return a NULL vector. Did I miss anything?

@kagamiori Wei, it could be the difference between element_at and [] operator:
presto> select array[][5];
Query 20230105_010832_05294_ae7g6 failed: Array subscript out of bounds

presto> select element_at(array[], 5);
 _col0
-------
 NULL
(1 row)

looks like out of bounds and invalid index (value of 0) gets handled a bit differently in element_at and subscript.
Both throw error for an invalid index of 0:
select element_at(myarray,0) from (SELECT ARRAY[] as myarray) a;
select myarray[0] from (SELECT ARRAY[] as myarray) a;
error:
(INVALID_FUNCTION_ARGUMENT) SQL array indices start at 1
Whereas for an index > 0 but out of bounds, element_at returns null but the subscript returns an error

@kagamiori Wei, it could be the difference between element_at and [] operator:
presto> select array[][5];
Query 20230105_010832_05294_ae7g6 failed: Array subscript out of bounds

presto> select element_at(array[], 5);
 _col0
-------
 NULL
(1 row)

Is this "[]" operator the "subscript" function in Velox? We implement both subscript and element_at using the same class template "SubscriptImpl". If they behave differently, then we need to add a parameter to control that.

OK, I think it's the "allowOutOfBound" parameter of SubscriptImpl that should control this behavior.

@kagamiori Just confirmed via a quick unit test that after my fix for this issue, for an out of bounds index, the element_at returns null but subscript throws error. So it will conform with Presto in that regard and we should be good.

@kagamiori Just confirmed via a quick unit test that after my fix for this issue, for an out of bounds index, the element_at returns null but subscript throws error. So it will conform with Presto in that regard and we should be good.

Are you going to send the fix? I can help review it then.

@kagamiori Just confirmed via a quick unit test that after my fix for this issue, for an out of bounds index, the element_at returns null but subscript throws error. So it will conform with Presto in that regard and we should be good.

Are you going to send the fix? I can help review it then.

Yes, just wrapping up writing unit tests, should push a PR soon. Thanks for volunteering to review!

Looks like there is no E2E test for this corner case of subscript() in Prestissimo. We should add it after we fix this divergence.
https://github.com/prestodb/presto/blob/a1a9299e054173ed380e1e6704310ff9c9b8e0a0/presto-native-execution/src/test/java/com/facebook/presto/nativeworker/TestHiveQueries.java#L528-L533


Secure Ingress Gateway

$ istioctl version --short
1.1.6
$ kubectl version --short
Client Version: v1.12.4+icp
Server Version: v1.12.4+icp

I am following this link to secure ingress gateway using secure service discovery process - https://istio.io/docs/tasks/traffic-management/secure-ingress/sds/
And, I used the example way to create certs and keys (https://github.com/nicholasjackson/mtls-go-example) - it works like a charm - no issues at all.
I also tried the step way to create the certificate and keys and created the secret just by following the example given above but it did not work for me (Obviously I made some mistake or missed something.)
These are the commands that I used using step.
And, I followed the instructions from the link in istio.io doc site.
step certificate create --profile root-ca "My Root CA" root-ca.crt root-ca.key
step certificate create istio.io istio.crt istio.key --profile intermediate-ca --ca ./root-ca.crt --ca-key ./root-ca.key
step certificate create httpbin.istio.io httpbin.crt httpbin.key --profile leaf --ca istio.crt --ca-key istio.key

Then, I created Kubernetes secret using:
kubectl -n istio-system create secret generic httpbin-keys --from-file=key=./httpbin.key --from-file=cert=./httpbin.crt

Then, I tried the curl to test this:
curl -HHost:httpbin.istio.io --resolve httpbin.istio.io:$INGRESS_PORT:$INGRESS_HOST --cacert ./istio.crt https://httpbin.istio.io/status/418

The httpbin.istio.io is defined to a local IP address defined in /etc/hosts
And, I get connect refused.
The only difference that I see is this. The mtls-go-example uses RSA keys whereas step uses EC keys. The step is super easy and intuitive to use and it uses defaults that are predetermined.
Step example:
-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,ab024c4bdd6009276ec5caac1e56ee28

ySop [removed] iBKG9inEA=
-----END EC PRIVATE KEY-----

Can someone help on this issue by the way of explanation or something that I did not do right.
Just on other note: Step is used in Linkerd for mTLS and it is fully automated and very simple to use. One thing that I liked about step is to not to know arcane openssl syntax that requires lots of experience or knowledge and step also provides simple to use online ca step-ca.

Seems that this is because the secret generated by step cli is different from the mtls-go library in the guide. I will test the step cli and compare the key/cert, and check the ingress gateway proxy log to find out whether Envoy accepts the key/cert generated by step cli.

@JimmyCYJ  - Thank YOU. I again tested by choosing RSA same way it is chosen by mtls-go-example but it did not work.
These are the commands I used:
step certificate create --profile root-ca "My Root CA" root-ca.crt root-ca.key -kty RSA --size 4096
step certificate create istio.io istio.crt istio.key --profile intermediate-ca --ca ./root-ca.crt --ca-key ./root-ca.key -kty RSA --size 4096
step certificate create httpbin.istio.io httpbin.crt httpbin.key --profile leaf --ca ./istio.crt --ca-key ./istio.key -kty RSA --size 2048

This is what I get:
curl -HHost:httpbin.istio.io --resolve httpbin.istio.io:$INGRESS_PORT:$INGRESS_HOST --cacert ./istio.crt  https://httpbin.istio.io/status/418
curl: (7) Failed connect to httpbin.istio.io:443; Connection refused

Hi everyone, step maintainer here. I don't have a working istio install, so I can't conveniently repro this, but I've got a pretty good theory about what's going on.
I'm fairly certain that Envoy works with the EC (P-256) keys that step produces by default. I don't think that's the problem.
I suspect the problem is that, by default, step password-encrypts all key material before writing to disk. Envoy wants unencrypted keys.
To clarify, here's the flow with some annotations showing where step prompts for passwords to encrypt & decrypt key material:
$ step certificate create --profile root-ca \
    "My Root CA" root-ca.crt root-ca.key
Please enter the password to encrypt the private key:    # This password is used to encrypt root-ca.key
Your certificate has been saved in root-ca.crt.
Your private key has been saved in root-ca.key.

$ step certificate create istio.io \
    istio.crt istio.key --profile intermediate-ca \
    --ca ./root-ca.crt --ca-key ./root-ca.key
Please enter the password to decrypt ./root-ca.key:      # step asks for root-ca.key password so it can use it to sign istio.crt
Please enter the password to encrypt the private key:    # This password is used to encrypt istio.key
Your certificate has been saved in istio.crt.
Your private key has been saved in istio.key.

$ step certificate create \
    httpbin.istio.io httpbin.crt httpbin.key \
    --profile leaf --ca istio.crt --ca-key istio.key
Please enter the password to decrypt istio.key:         # step asks for istio.key password so it can use it to sign httpbin.crt
Please enter the password to encrypt the private key:   # This password is used to encrypt httpbin.key
Your certificate has been saved in httpbin.crt.
Your private key has been saved in httpbin.key.
                                   # ^- This file ends up encrypted. We don't want it to be.

$ cat httpbin.key
-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED                                  # <- This PEM header indicates that the payload is encrypted
DEK-Info: AES-256-CBC,31521e639e37081328b011d714fadba1  # <- The encryption algo (AES-256-CBC) and initialization vector

DhTSHVnKnOvm7wDExyJbB/R6u/TibU9lShMiDJWxTHvc2qw/lqWjDW/+//c8Xlsz
10skiOLp3oEo+3bbQ6ICMUBs8OGb6QWJBQmeoleKNwtQNqsRRWO5Ojaad/7MZNoD
pbxgffG3CSqtGuZkKu893O8CMMb3r5zamkquokDLe4E=
-----END EC PRIVATE KEY-----

It's fine that the root-ca.key and istio.key signing keys are encrypted. But we need the httpbin.key key to be unencrypted. This is easy to achieve using step by passing the --no-password & --insecure command line flags when we create httpbin.key:
step certificate create httpbin.istio.io httpbin.crt httpbin.key \
  --profile leaf --ca istio.crt --ca-key istio.key \
  --no-password --insecure

Note that the --insecure flag is required when you use --no-password to prevent accidental misuse (we want to make it really obvious when you try to do something potentially dangerous).
I suspect that adding these flags will make the above example work.
That said, there is another subtle issue with the series of commands used above. We're generating a root and intermediate certificate, but we're not bundling the intermediate certificate with the leaf. The curl command above will probably still work, however, because it's passing the intermediate certificate (istio.crt) as the --cacert. In the real world this probably isn't what you want, because it'd force you to distribute your intermediate certificate everywhere, which would reduce the value of having an intermediate at all.
To fix this second issue we need to bundle the root and intermediate certificate (i.e., put the two certificates together in one file) and pass this bundle in our kubectl invocation instead of the unbundled httpbin.crt. The step ca bundle subcommand can help with this.
Here's a series of commands that I believe should work:
step certificate create --profile root-ca "My Root CA" root-ca.crt root-ca.key
step certificate create istio.io istio.crt istio.key --profile intermediate-ca --ca ./root-ca.crt --ca-key ./root-ca.key
step certificate create httpbin.istio.io httpbin.crt httpbin.key --profile leaf --ca istio.crt --ca-key istio.key --no-password --insecure
step certificate bundle httpbin.crt istio.crt httpbin-bundle.crt
kubectl -n istio-system create secret generic httpbin-keys --from-file=key=./httpbin.key --from-file=cert=./httpbin-bundle.crt
curl -HHost:httpbin.istio.io --resolve httpbin.istio.io:$INGRESS_PORT:$INGRESS_HOST --cacert ./root-ca.crt https://httpbin.istio.io/status/418

If someone can give that a try I suspect it will fix the problem.
As a footnote, I'm pretty sure the generate.sh script linked above has a different subtle quirk (I hesitate to call it a bug) around bundling. It appears to be "bundling" the intermediate and root certificates instead of bundling the intermediate & leaf certificates. Again, it'll still work, but I'm pretty sure it's not behaving as the author expects and it's not how things are normally done. Instead, the leaf & intermediates should be bundled and only the root ca.cert.pem should be used in the curl invocation.

@mmalone @JimmyCYJ @morvencao
Mike - Thank YOU. This worked.
First time - it did not. But, when I recycled istio-ingressgateway pod - it worked perfect.
Here is the teapot.
curl -vvv -HHost:httpbin.istio.io --resolve httpbin.istio.io:$INGRESS_PORT:$INGRESS_HOST --cacert /root/step/istio.crt https://httpbin.istio.io/status/418
* Added httpbin.istio.io:443:<IP_ADDRESS> to DNS cache
* About to connect() to httpbin.istio.io port 443 (#0)
*   Trying <IP_ADDRESS>...
* Connected to httpbin.istio.io (<IP_ADDRESS>) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /root/step/istio.crt
  CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=httpbin.istio.io
*       start date: May 18 00:38:52 2019 GMT
*       expire date: May 19 00:38:52 2019 GMT
*       common name: httpbin.istio.io
*       issuer: CN=istio.io
> GET /status/418 HTTP/1.1
> User-Agent: curl/7.29.0
> Accept: */*
> Host:httpbin.istio.io
>
< HTTP/1.1 418 Unknown
< server: istio-envoy
< date: Sat, 18 May 2019 01:10:01 GMT
< x-more-info: http://tools.ietf.org/html/rfc2324
< access-control-allow-origin: *
< access-control-allow-credentials: true
< content-length: 135
< x-envoy-upstream-service-time: 5
<

    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`
* Connection #0 to host httpbin.istio.io left intact

Thank you @mmalone for the detailed explanation and helpful solutions!
Since the problem is solved, I will close the issue for now. Feel free to reopen it if any other issue is found.


Bugfix: fix failure with alm-examples when not specified in metadata

The previous bugfix does not consider the case when the alm-examples key is not specified in data.
The following bugfix handles it.

example output :
[srallaba@localhost cvp_1683]$ cat opb_bug_fix/operator-test-playbooks/*.json
{
"msg": {
"_ansible_no_log": false,
"changed": false,
"failed": true,
"msg": "Failed due to CSV.metadata.annotations['alm-examples'] is set to empty"
},
"result": "fail"
}

/test

LGTM

/test

@14rcole Need approval to merge.
I forgot to add anyone to reviewers before,

/retest


Add StackStorm workflow for provision volume

Codecov Report

Merging #7 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #7   +/-   ##
=======================================
  Coverage   65.51%   65.51%
=======================================
  Files           3        3
  Lines          29       29
  Branches        1        1
=======================================
  Hits           19       19
  Misses          9        9
  Partials        1        1

@joseph-v , why there is no description for this? Probably we reject and raise again?

@joseph-v please rebase your commit


Docker-based function app Encountered an error (InternalServerError) from host runtime

I'm working with an Docker-based Python function app on B1 linux service plan in Australia East. It was working well until today, when it stopped.
When I click on a function name in the function app blade, there is a small popup window with error "The function runtime is unable to start. ". If I try to navigate to Manage part of a function, there is also a second popup window with message "Encountered an error (InternalServerError) from host runtime. "
The app still works fine in debugging mode, deployment process doesn't indicate any errors, and function app shows in the portal as Running and Available.
I tried to delete, recreate and redeploy the whole app, but to no avail.
Are there any logs I can check?

Alright. I deleted the func app, service plan, and purged the associated storage account, then redeployed everything. Then it started working well. Is it how it's supposed to be?

@bukarev Typically InternalServerError stems from a problem on the platform side, not VS Code. Let me know if you can get consistent repro steps from VS Code and I can investigate. The platform team actually just just announced GA of Python and Linux Consumption (see here) so hopefully it should be more reliable now anyways

Let's close it for now, as I did a couple of successful redeployments of the Function App in question after I purged the associated storage account.


[SPARK-20365][YARN] Remove LocalSchem when add path to ClassPath.

What changes were proposed in this pull request?
In Spark on YARN, when configuring "spark.yarn.jars" with local jars (jars started with "local" scheme), we will get inaccurate classpath for AM and containers. This is because we don't remove "local" scheme when concatenating classpath. It is OK to run because classpath is separated with ":" and java treat "local" as a separate jar. But we could improve it to remove the scheme.
How was this patch tested?
Updated ClientSuite to check "local" is not in the classpath.
cc @jerryshao

Can one of the admins verify this patch?

CC @vanzin to take a review.

ok to test

Test build #77596 has started for PR 18129 at commit 79105f8.

Test build #77596 has finished for PR 18129 at commit 79105f8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77596/
Test PASSed.

Test build #77623 has started for PR 18129 at commit 683f0d9.

Test build #77623 has finished for PR 18129 at commit 683f0d9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77623/
Test PASSed.

Test build #77645 has started for PR 18129 at commit 35e5859.

Test build #77645 has finished for PR 18129 at commit 35e5859.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/77645/
Test PASSed.

Merged build finished. Test PASSed.

Merging to master / 2.2.

@liyichao please update the bug with your JIRA handle if you want it assigned to you.


Changelog auto generation

Fixes  #83

Changelog has to be generated only after relase pipeline suceeded.

@Jaredeco You are pushing also another unrelated commit, please remove it.
Hint: do a backup of your branch before working with commits/rebasing...


MIT License?

Hi there!
I'd love to run your benchmarks and integrate them into my testing process for Pyoframe however the code would need to be open source for that to be possible. Let me know if you think it can be done!
Martin

License has been clarified as MIT like the JuMP benchmark.


Lemma numbering

Right now, we throw away lemma numbers when we print them.
We refer to the lemmas by their numbers in the proof output, however.
Two options:

Don't add numbers. Rely on lemma ordering
Add numbers to things. Need to add to regular assertions also though, so breaks TIP backwards compatibility

Lemma naming now present


Add worker task to VS Code

After following https://docs.inventree.org/en/stable/develop/devcontainer/ I was wondering why the queue isn't processed. Maybe I used wrong search keywords, but I haven't found another solution than to invoke a worker manually.
So I extended tasks.json to have vscode support.
I created this PR as a draft, because it's probably the wrong way to deal with workers. Maybe the devcontainer should have a worker already running? So I'm open for feedback.

I think it makes sense to implement it like this - although we should also include in this PR an update to the documentation (in the devcontainer section) describing the new task for the background worker.

Ok nice. But documentation is another repository, right? So should I create a PR there as well?

No, documentation was moved into the main repo a while a go. You find it in the docs/ folder.

OK then this should be part of this PR as well, I'll try to push additional changes

@matmair @SchrodingersGat I merged in master and added documentation, happy to see some feedback :)

@lippoliv looks good to me, thanks for the contribution :)


We may need to do something about Google Analytics July 2023

https://support.google.com/analytics/answer/11583528?hl=en
We use GA to record opt-in anonymous data about Prototype Kit usage, it seems we may need to do something to update this by July 2023

@joelanman is this still valid or can it be closed?

still valid! It relates to the kit stats, not the site stats


Update README.md

Coverage remained the same at 98.684% when pulling f460acb72cc20e454a0449d770b00fba0956dcfe on myxobek:patch-1 into 9c6da3854e75b07b4b6c3fdaf444ca635ae148f0 on pda:master.

Resolved conflicts.


removing or not requiring project observation field doesn't remove the project observation rule

Well, despite seeing some evidence that this might be happening on the site, I was unable to replicate it locally, and we have code and tests covering this: https://github.com/inaturalist/inaturalist/blob/master/spec/models/project_observation_field_spec.rb


Customize the 'NavbarBrand' name

The top navigation bar has the logo and the name.
The logo is customizable, but the name is not.
Allow sub-classes of DashApp to customize the name/brand in the navigation bar.
See DashApp.get_navbar()

Also added DashApp constructor argument navbar_brand_name: Optional[str].


LWSHADOOP-361: mapr 5 support.

Looks good cesar, feel free to merge into the master

Nm ... I went ahead and did it ;-)


[BUG] Sharing Keycloak setup, not exactly a bug but certainly felt like one

Environment
Self-Hosted (Docker)
System
Docker 25
Version
3.0
Describe the problem
It wasn't very smooth for me to get Dashy 3.0 and KC 24.0.3 working together, but I kinda got there, so sharing my settings that may help others. Also there's a bit bug like behavior, not sure which side it originate from, or just need a documentation update
Most of Dashy doc are good, here are some crucial details
In TC clients,
"Client authentication" must be switched off, otherwise it gets into a redirect loop, or at least that's how it looks like to me.
In TC clients -> Advanced -> OpenID Connect Compatibility Modes,
"Exclude Issuer From Authentication Response " must be switched on. Otherwise it redirects to "https://dashy.my.domain/#iss=https://keycloak.my.domain/realms/my-realm"
You can still login to dashy, but refresh, logout will generate in TC error="invalid_redirect_uri"
In TC clients -> Access settings, if you are using multiple dashy pages, you need

Root URL   https://dashy.my.domain/   (with/wo trailing / doesn't matter)
Valid redirect URIs must be    /*

Otherwise other pages will generate in TC error="invalid_redirect_uri"
With above steps, I got KC working ok, but show/hide based on group/role still doesn't work, raised here https://github.com/Lissy93/dashy/issues/1550
Additional info
No response
Please tick the boxes

[X] You have explained the issue clearly, and included all relevant info
[X] You are using a supported version of Dashy
[X] You've checked that this issue hasn't already been raised
[X] You've checked the docs and troubleshooting guide
[X] You agree to the code of conduct

Hello all,
For anybody using Dashy authentication, please read the following posts:

https://subract.dev/posts/dashy/
https://github.com/Lissy93/dashy/issues/668#issuecomment-2024390223

Read carefully before using Dashy exposed to the internet.

Hi
I created a PR for this: https://github.com/Lissy93/dashy/pull/1581.
Once it gets merged i'll close this here.
Regarding the Post by subtract, view the recent post by lissy: https://github.com/Lissy93/dashy/discussions/1579


Possibility to add competitor to the app

Would it be possible to add the competitor also to the app.
Maybee make it a universal Pool meter App .
For now there are just 2 brands that offer a non professional device.
Ico and BlueRiiot with the blue connect
https://www.blueriiot.com/eu-en/products/blue-connect-plus
The API info can be found at:
https://github.com/LordMike/MBW.Client.BlueRiiotApi/tree/master/src/MBW.Client.BlueRiiotApi
Would be great . Can even supply you with credentials to test OFC

Interesting idea! I took a quick look and it sure looks possible.
On the other hand, Athom states that there should be 1 app per brand. I don't know how they feel about a 'generic pool' app though...

The solar panel app also has multiple brands . So had the temperature sensor app.
The Tuya app even has 14 brands combined already because all brands a same way of doing it .
I have the gledopto and tint brands combined in one app
Guess they won’t mind
Verstuurd vanaf mijn iPhone

Op 23 apr. 2021 om 13:41 heeft Edwin van de Pol @.***> het volgende geschreven:

Interesting idea! I took a quick look and it sure looks possible.
On the other hand, Athom states that there should be 1 app per brand. I don't know how they feel about a 'generic pool' app though...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.