MinMdns - do not reset hasIP/hasHostPort on partial failure

MinMdns can receive several packets and if any of the packets are ok,
a single valid ip or host/port is sufficient.
In practice, this was failing on mdns on ipv6 only builds when both ipv6
and ipv4 were sent in order. Specifically:

MDNS packet contains AAAA followed by A
Resolver parses AAAA and sets a valid IP
Resolver sees A and fails to parse (no IPv4 support) and resets
valid IP

As a result, dns resolution was never calling complete (because it
thinks no valid IPs).

Moving to draft temporarely until fully validated.
The changes to A/AAAA logic (for mHasIP) were validated, however our logic for mHasHostPort seems to potentially have some logic issues. Waiting to merge only once this is validated.

Marking back as ready for review: I believe this is a net improvement over previous code.

Yeah, verified that we need it to get anywhere with our DUT.  Came here to say +1
but it's already merged.
:)


feat(storage): introduce metrics for tiered cache

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
Introduce metrics for tiered cache to monitor total cache access and cache miss.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Refer to a related PR or issue link (optional)
#4518

BTW, is this L315 right? When the cache policy is Disable, sstable store also calls fetch_block which will step the cache miss counter by 1.
https://github.com/singularity-data/risingwave/blob/c6f1a19af5a0b483157b9647ce66224e3f170614/src/storage/src/hummock/sstable_store.rs#L314-L315

BTW, is this L315 right? When the cache policy is Disable, sstable store also calls fetch_block which will step the cache miss counter by 1. cc @wenym1 @hzxa21
https://github.com/singularity-data/risingwave/blob/c6f1a19af5a0b483157b9647ce66224e3f170614/src/storage/src/hummock/sstable_store.rs#L314-L315

This is not right :(
We shouldn't update cache metrics if the cache policy is Disable...

Duplicated with #4786 , close.


feat: enable HD wallet import

Checklist

[ ] JIRA - <link>
[ ] Proper tests implemented
[ ] Screenshots added.

Proposed solution
Explain how does this PR solves the problem stated in JIRA ticket.
You can also enumerate different alternatives considered while approaching this task.
Testing
Describe here, how the new implementation can be tested.
Provide link or briefly describe User Acceptance Criteria/Tests that need to be met
Screenshots
Attach screenshots here if implementation involves some UI changes

Allure report
allure-report-publisher generated test report!

smokeTests: ❌ test report for a1b98abf

passed
failed
skipped
flaky
total
result

Total
35
1
0
0
36
❌

Great job @mchappell!


Align support for multiple operation-files and multiple schema-files

Multiple schema-files are now supported as of #134, but the support was
a bit different from how we did multiple operation-files.  Before anyone
starts to depend on the ways the syntaxes differ, let's just make them
the same.  Since it's easy, I also added support for having just a
single operations-file.
I also realized while writing this that the type-change is technically
breaking (if you call from Go), so documented it as such. I think
this is unlikely to affect many people.
Test plan: make check

cc @hsblhsn if you wanted to take a look!  If it's an issue we could move to using the fancier globbing for both.


Passport support and custom migration table names

This pull request have the following points:

Added supporting custom migration table name (getting from Laravel configurations instead fixing it as migrations
Change the middleware from auth:basic to auth:api to support Passport authenticated requests
Small change in composer.json adding prefer-stable parameter to not install all dependencies using dev-master, only when it is explicit

Coverage remained the same at 99.659% when pulling 7830c0962c8899871c89918b2dda71a6ac13622f on renanwilliam:master into ac47031d5b2d405e42fb689c5bb6f84a57d341a5 on Algo-Web:master.

Hi, excuse my own lack of knowledge, but can you explain the difference between auth.basic and auth.api I have assigned this pull request to @CyberiaResurrection who is our Laravel Guru.

Very solid work, @renanwilliam .  I only have one thing that I'd like you to resolve - could you please make your changes polyglot (ie, works as well on version A as version B) across Laravel 5.1 as well?  Otherwise, rolling this up as is would break projects (such as a couple I'm hacking on, one commercially) that are on Laravel 5.1.
My goal is to make POData-Laravel polyglot across Laravel 5.1 through 5.5.
Simplest way I can see to do that for your pull request would be to check if auth.api is registered and use that in the middleware choice in the MetadataRouteProvider, else drop back to auth.basic.
If you've got any more pull requests of this quality, send them through - I'd love to see more.

Now that I've bolted in a L5.1 test case to the travis file, @renanwilliam can you rebase this pull request against master and see if my fears about breaking 5.1 are grounded?

Hi @CyberiaResurrection,
Added the check for auth:api existence before use it to make works without Passport (L5.3-).
Thinking here about this problem, a good feature for future is include the middleware in config section to make it more flexible.

Coverage increased (+0.006%) to 99.665% when pulling 0603b9982178d2eadbb0091304d7fc62ada95dca on renanwilliam:master into ac47031d5b2d405e42fb689c5bb6f84a57d341a5 on Algo-Web:master.

Coverage decreased (-0.2%) to 99.466% when pulling 72bb65f8fbc69daa1766e9d61af718216b651ed4 on renanwilliam:master into ac47031d5b2d405e42fb689c5bb6f84a57d341a5 on Algo-Web:master.

Coverage decreased (-0.3%) to 99.398% when pulling 72bb65f8fbc69daa1766e9d61af718216b651ed4 on renanwilliam:master into ac47031d5b2d405e42fb689c5bb6f84a57d341a5 on Algo-Web:master.

Looks ok so far - but from what you've told me, when running under L5.3+, it should take the if branch on line 50 of the MetadataRouteProvider, and the else branch under L5.1.
From the coverage reports, under both L5.1 and L5.4/5 (depending on PHP version), getAuthMiddleware seems to be returning auth.basic - ie, going down the else branch on line 50.  Is there a dependency package missing?

Hi @CyberiaResurrection ,
Yes, for L5.3+ the API authentication is managed in a additional package laravel/passport. It's necessary some additional configuration steps, that are described in documentation.
But I think that it must return auth:api anyway because the 'auth:api' guard is defined out-the-box in a fresh L5.4 install. What is the Laravel version defined for coverage report generator for L5.1+?

The ">5.1.11" cases are running L5.4 for PHP 5.6, and L5.5 (current dev version) for PHP 7+.
I pulled your changes down to my local machine (running PHP 5.6, so L5.4 - I didn't add any further dependencies) and I could get that if branch to fire by changing the class_exists(\Illuminate\Contracts\Auth\Factory::class)  to interface_exists(\Illuminate\Contracts\Auth\Factory::class).
Dropping my local copy back to L5.1 meant that the else branch fired instead.

@renanwilliam , how could you go about writing a set of tests that verify that the correct route middleware is hooked up?
Your changes imply the following test cases that need to be looked at: auth.basic for L <5.3, auth.basic for L5.3+ without the api guard middleware, and auth:api for L5.3+ with the api guard?

This was merged up as part of #70

@CyberiaResurrection sorry, I have more available time at weekends. I have seen that you have created the tests, thank you!
Thanks also @c-harris!

No need to apologise @renanwilliam  - I wanted to give you the credit for the fix as well as the original patch.  If you check the CHANGELOG.md in master, you should see your name in lights there.
Thank you for your (possibly inadvertent) project-level bug reports that rumbled issues like lack of L5.1 in the test suite, etc.

Thanks for that. hope that I and my company can contribute more with the package in future @CyberiaResurrection, we will try use it with OpenUI5 in some new projects that will start in the next month.

I certainly won't object to more pull requests and bug reports of the same quality as you've managed so far.  I'll definitely have to put a "don't drop coverage level" requirement into the contributor's guide.


[FLINK-6587] [table] Simplification and bug fixing of the ExpressionParser

This PR fixes several issues related to the ExpressionParser and the resolution of expression produced by it. Only special cases are handled by the parser, other expressions will resolved by the function catalog. I also updated the data types such that they are in sync with org.apache.flink.table.api.Types.

@twalthr, it seems we have reserved the keyword with the case insensitive. For instance, we cannot use "Sum" and "SUM", as "sum" is reserved. Did we intent to filter the keyword like this?

@shaoxuan-wang the function catalog is case insensitive anyway. With this PR we have almost no keywords anymore. So a "sum" could be overwritten by "SUM".

The PR looks good to me. +1 from my side.

Thanks @fhueske. I will merge this and update the documentation.


editor.formatOnSaveMode does not appear to function

Testing #105733

Create a file file.ts
Paste the following contents:

class A {
private foo(): number {
return 5;
}
}

Close the file and reopen vscode
Configure "editor.formatOnSaveMode": "modifications"
Configure "editor.formatOnSave": true
Paste the following contents in the file:

class B {
private foo(): number {
return 5;
}
}

Save file via cmd+s to get the format on save running
Observe that class A has been formatted:

@alexdima modifications are based on SCM diff information. Your file appears as untracked and no quick diff markers show. Do you really have only those lines "SCM modified"?

I can also repo, I have the same settings from above ("editor.formatOnSaveMode": "modifications", and "editor.formatOnSave": true) and I expect only to have line 10 formatted but then other lines get formatted.

@misolori you are on the right path. Modifications are being formatted but my assumption is that I pass  the range 10,1-11,1 to the html formatter and that it then over-eagerly formats the whole statement of line 11.
@alexdima ping for clarification

@jrieken I see, I misunderstood the feature. Maybe the setting could make it more clear that this is only about SCM diff ranges. I thought that the file is read from disk just before saving and a diff is computed with the state on disk. It was not clear to me that the diff is computed with the state of the index.

The setting says "requires source control"... I actually like your assumption of how it should/could work and that's maybe something for the future. So, maybe we find an alternative for "modified" that expresses it's "source control modified" and then, in the future, we have another option that says "modified in session". Ideas?

:+1: Sorry about my confusion. I didn't use the settings ui and this was my experience:

Yeah, the suggestion details widget would show this... Still open for suggestion for a better name and maybe give this a short test run after all
@misolori can you share the file and what formatter your are using? I wasn't able to reproduce what you see.

So it looks like that may have been an issue with my formatter (Prettier). Disabled that and used the default one and got it working for JS files.
However, I'm not seeing this work reliably with JSON files. Some format commands don't work (Format Selection and Format Modified Lines) but Format Document does work 🤷♂:

Yeah, the secret of "format modified" is that it does "format selection" where the selection isn't visible and consists of the modified ranges. Adding @aeschli who did the JSON formatter - it might be fit for arbitrary range formattings

Seeing similar things with the HTML formatter. This works fine in other JS/TS files though. Hopefully these bugs can get fixed and are not by design.

I have created https://github.com/microsoft/vscode/issues/105998 to track selection formatting issues. Closing this as the @alexdima's confusion has been cleared


Moved middleware up to actions

Action now have middleware support. Removed models specific implementation, models now use common middleware.
Ex:
    const act = action({
      name: 'foo',
      inputSchema: z.string(),
      outputSchema: z.number(),
      use: [
        async (input, next) => await next(input + 'middle1') + 1,
        async (input, next) => await next(input + 'middle2') + 2,
      ]
    }, async (input) => {
      return input.length
    });

Thanks, Pavel! 🤙🏼 ✨

I've been meaning to revive this for weeks, thanks Pavel! ❤


fix(eds/store): IPLD blockstore cleanup

Individual IPLD blocks are stored in the edsstore's blockstore as of #2532. These blocks need to eventually be cleaned up. There are two approaches we briefly discussed:

GC approach: Every X minutes/hours all blocks under the datastore prefix are purged. The non-trivial part here is that it may remove blocks that are currently being used for reconstruction.
Post-reconstruction removal: Trigger removal of all of the IPLD blocks of an EDS upon successful retrieval. This can be done by adding a hook somewhere where the CIDs are known (such as inside retriever.go or after indexing). The non-trivial part here is not making it extremely ugly

shwap

Initially, shwap aimed to address this by implementing an enhanced retriever. However, following an internal discussion on shwap's scope, we decided against including retriever improvements. Therefore, this issue will need to be addressed separately from shwap.


Scripts flattened into a different namespace

This PR moves Sprocs, UDFs, and Triggers away from CosmosContainer and into their own namespace and flattened into CosmosScripts.
In order to get the CosmosScripts reference, an extension method under namespace Microsoft.Azure.Cosmos.Scripts was created.
Refactoring of the CosmosStoredProcedures, CosmosUserDefinedFunctions, and CosmosTriggers types was done, removing plural classes and moving those methods into CosmosScripts.
This PR fixes #167

Please create an issue (Breaking tag) with details and map to this PR.
It will help us on release notes tracking as well.

Can you please update the description with the latest design changes?


Limit number of entries

The generation of the change log needs a long time if there are lot of commits on the considered branch. During this time, bitbucket server does not respond  - even for other users trying to access other repositories.
The plugin shouldn't tear down the bitbucket server performance as massively as it does now.
Is it possible to introduce a limitiation in changelog entries? Maybe a limitation in the number of commits which occur within the changelog - or a date limit (only use commits after ...) - or another limitation ...
In this context it would be nice if the settings are available per repository (not only globally as it is now ...)

Sounds good, and also #3 will help here.

Just realized that the lib can be greatly improved here:
https://github.com/tomasbjerre/git-changelog-lib/issues/13

How much time are we talking about? How many commits do you have?

I tried with the spring framework, 11000+ commits. It hangs and I get OutOfMemory... I'm not sure such large repos can ever be supported. There are commandline, jenkins, gradle and maven plugins that are perhaps better suited for those very large repos.
I'm open for a discussion here, any ideas are welcome. I think these featues would be nice.

Enable/disable per repository
Limit number of commits

Sry for the late answer
You wrote: "It hangs and I get OutOfMemory!" That's something we experienced too ....  As soon as we noticed that it runs very long - and our normal users cannot access to bitbucket anymore - we restarted the server to have it accessible again (so we did no experience the OutOfMemory as we restarted before)
Your proposed features are the same I thought about ...
Another nice feature would be:

Generate a changelog starting from tag "XXXX" ...

Concerning proposed fearure: "Enable/disable per repository"
On the page with the generated changelog, you already offer a possibility to select a tag, from where the changelog should be generated from. The selected tag should also be stored per repository and should be used as default value on next changelog generation.

I just released 1.2 to Marketplace. It should make a big difference in performance.
I'll try to find some time soon, to fix the other stuff mentioned here.


how to implement FP16 version of this repo?

@AlexeyAB thanks for your great work, because my GPU is 2080ti, I want to use the FP16 quantization and test the inference time of it. What should I do to implement the FP16?

found the solution.

Hello passion3394,
do you have hint about how to achieve this goal? Did you notice a valuable latency improvement with the FP16 network?
Thanks!

@AleBasso80 Yes, firstly, your GPU must support FP16, then use this repo to run yolo. On my datasets and 2080ti GPU, the inference time dropped from 75ms to 50ms.

@passion3394 do you mean that I don't have to modify any compilation setting or config parameter? Does the network automatically choose fp16 if this is supported?

@AleBasso80 Yes.

@passion3394 . Thanks!
Just one more question: I'm comparing the results of this repo with the standard yolo v2. I noticed that this one works better with lying or crawling people. I compared the networks (I'm not using the int8 quantization) and I found that they differ in the reorg layer and in the yolov2_fuse_conv_batchnorm(network net). It does not seem to me that the former can cause a significant difference, therefore I'm concentrating on the layer fusion. Do you think this is the right path?
Cheers

@AleBasso80 Why not use the method of Ablation Study?

@passion3394 : good advice. I'll do it, thanks!


Improve the readability of stack traces

I think we should improve the readability of the diagnostic event and stack trace outputs that the environment generates on the console and in tests when there are failures.
This is not about improving the contents / data within the diagnostic events, and only the presentation of the existing data, so it is easier to glance and digest.
An example of the existing output as of v21.2.1:
thread 'test::test_sample_policy_call_self' panicked at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:768:9:
HostError: Error(Auth, InvalidAction)

Event log (newest first):
   0: [Diagnostic Event] topics:[error, Error(Auth, InvalidAction)], data:"escalating error to panic"
   1: [Diagnostic Event] topics:[error, Error(Auth, InvalidAction)], data:["contract call failed", add, [[Policy, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4], [Temporary], [Admin]]]]
   2: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, topics:[error, Error(Auth, InvalidAction)], data:"caught error from function"
   3: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, topics:[error, Error(Auth, InvalidAction)], data:"escalating error to panic"
   4: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, topics:[error, Error(Auth, InvalidAction)], data:["Unauthorized function call for address", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM]
   5: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), add], data:[Policy, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4], [Temporary], [Admin]]
   6: [Diagnostic Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, topics:[fn_return, add], data:Void
   7: [Contract Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, topics:[sw_v1, add, [Ed25519, [Bytes(a1738d72617d88f775693c9b9033d8bbb99d127ea9ac0f04940dd090350c5b4e)]]], data:[Ed25519, [Admin]]
   8: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), add], data:[Ed25519, [Bytes(a1738d72617d88f775693c9b9033d8bbb99d127ea9ac0f04940dd090350c5b4e)], [Persistent], [Admin]]
   9: [Diagnostic Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, topics:[fn_return, add], data:Void
   10: [Contract Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM, topics:[sw_v1, add, [Secp256r1, [Bytes(f3f8d84ae2da5566c4a70e977c2a49888a66bb8c)]]], data:[Secp256r1, [Bytes(04a38ef5f2713768bd3480eeceaec2b10464a1f3b1ff0a3539c2cd2dd00a83a75d2c7b7e5fdbcfe6af5a602979c57fb44aeca0003cb9d3ae85d7c8d0e633d25ed6)], [Admin]]
   11: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), add], data:[Secp256r1, [Bytes(f3f8d84ae2da5566c4a70e977c2a49888a66bb8c)], [Bytes(04a38ef5f2713768bd3480eeceaec2b10464a1f3b1ff0a3539c2cd2dd00a83a75d2c7b7e5fdbcfe6af5a602979c57fb44aeca0003cb9d3ae85d7c8d0e633d25ed6)], [Persistent], [Admin]]

Backtrace (newest first):
   0: backtrace::backtrace::libunwind::trace
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/backtrace/libunwind.rs:93:5
      backtrace::backtrace::trace_unsynchronized
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/backtrace/mod.rs:66:5
   1: backtrace::backtrace::trace
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/backtrace/mod.rs:53:14
   2: backtrace::capture::Backtrace::create
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/capture.rs:176:9
   3: backtrace::capture::Backtrace::new_unresolved
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.69/src/capture.rs:170:9
   4: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info::{{closure}}
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:293:37
   5: soroban_env_host::budget::Budget::with_shadow_mode
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/budget.rs:972:21
   6: soroban_env_host::host::Host::with_debug_mode
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:615:24
   7: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:290:13
   8: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error::{{closure}}
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:274:23
   9: soroban_env_host::budget::Budget::with_shadow_mode
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/budget.rs:972:21
  10: soroban_env_host::host::Host::with_debug_mode
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:615:24
  11: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:261:9
  12: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:767:26
  13: soroban_sdk::env::internal::reject_err::{{closure}}
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:52:23
  14: core::result::Result<T,E>::map_err
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
  15: soroban_sdk::env::internal::reject_err
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:52:9
  16: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:1667:13
  17: soroban_sdk::env::Env::invoke_contract
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:379:18
  18: webauthn_wallet::ContractClient::add
             at src/lib.rs:28:1
  19: webauthn_wallet::test::test_sample_policy_call_self
             at src/test.rs:128:5
  20: webauthn_wallet::test::test_sample_policy_call_self::{{closure}}
             at src/test.rs:30:34
  21: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5

stack backtrace:
   0: rust_begin_unwind
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
   2: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:768:9
   3: soroban_sdk::env::internal::reject_err::{{closure}}
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:52:23
   4: core::result::Result<T,E>::map_err
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
   5: soroban_sdk::env::internal::reject_err
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:52:9
   6: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:1667:13
   7: soroban_sdk::env::Env::invoke_contract
             at /Users/tylervanderhoeven/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.0/src/env.rs:379:18
   8: webauthn_wallet::ContractClient::add
             at ./src/lib.rs:28:1
   9: webauthn_wallet::test::test_sample_policy_call_self
             at ./src/test.rs:128:5
  10: webauthn_wallet::test::test_sample_policy_call_self::{{closure}}
             at ./src/test.rs:30:34
  11: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
  12: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5

Some outputs of panic outputs in different environments for inspiration are below. They use very simple inputs, so their utility may be limited, but maybe we can learn something from them.
Rust
fn main() {
	f1(1)
}

fn f1(i: u32) {
	f2()
}

fn f2() {
	f3()
}

fn f3() {
	panic!("oh no")
}

thread 'main' panicked at src/main.rs:14:5:
oh no
stack backtrace:
   0: rust_begin_unwind
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
   2: ruttest::f3
             at ./src/main.rs:14:2
   3: ruttest::f2
             at ./src/main.rs:10:2
   4: ruttest::f1
             at ./src/main.rs:6:2
   5: ruttest::main
             at ./src/main.rs:2:2
   6: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5

Go
package main

func main() {
	f1(1)
}

func f1(i int) {
	f2()
}

func f2() {
	f3()
}

func f3() {
	panic("oh no")
}

panic: oh no

goroutine 1 [running]:
main.f3(...)
        /Users/leighmcculloch/Code/gotest/main.go:16
main.f2(...)
        /Users/leighmcculloch/Code/gotest/main.go:12
main.f1(...)
        /Users/leighmcculloch/Code/gotest/main.go:8
main.main()
        /Users/leighmcculloch/Code/gotest/main.go:4 +0x38
exit status 2

Node
function f1(i) {
  f2();
}

function f2() {
  f3();
}

function f3() {
  throw "oh no";
}

f1(1);

/Users/leighmcculloch/Code/nodtest/main.js:10
  throw "oh no";
  ^
oh no
Thrown at:
    at f3 (/Users/leighmcculloch/Code/nodtest/main.js:10:3)
    at f2 (/Users/leighmcculloch/Code/nodtest/main.js:6:3)
    at f1 (/Users/leighmcculloch/Code/nodtest/main.js:2:3)
    at /Users/leighmcculloch/Code/nodtest/main.js:13:1
    at Module._compile (node:internal/modules/cjs/loader:1378:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1437:10)
    at Module.load (node:internal/modules/cjs/loader:1212:32)
    at Module._load (node:internal/modules/cjs/loader:1028:12)
    at executeUserEntryPoint (node:internal/modules/run_main:142:12)
    at node:internal/main/run_main_module:28:49

Bun
function f1(i) {
  f2();
}

function f2() {
  f3();
}

function f3() {
  throw "oh no";
}

f1(1);

error: oh no

Deno
function f1(i: u32) {
  f2();
}

function f2() {
  f3();
}

function f3() {
  throw "oh no";
}

f1(1);

error: Uncaught (in promise) "oh no"

Python
def f1(i):
  f2()

def f2():
  f3()

def f3():
  raise Exception("oh no")

f1(1)

Traceback (most recent call last):
  File "/Users/leighmcculloch/Code/pytest/main.py", line 10, in <module>
    f1(1)
  File "/Users/leighmcculloch/Code/pytest/main.py", line 2, in f1
    f2()
  File "/Users/leighmcculloch/Code/pytest/main.py", line 5, in f2
    f3()
  File "/Users/leighmcculloch/Code/pytest/main.py", line 8, in f3
    raise Exception("oh no")
Exception: oh no

Ruby
def f1(i)
  f2()
end

def f2()
  f3()
end

def f3()
  raise "oh no"
end

f1(1)

main.rb:10:in `f3': oh no (RuntimeError)
        from main.rb:6:in `f2'
        from main.rb:2:in `f1'
        from main.rb:13:in `<main>'

Java
public class Main {
    public static void main(String[] args) {
        f1(1);
    }

    public static void f1(int i) {
        f2();
    }

    public static void f2() {
        f3();
    }

    public static void f3() {
        throw new RuntimeException("oh no");
    }
}

Exception in thread "main" java.lang.RuntimeException: oh no
  at Main.f3(Main.java:15)
  at Main.f2(Main.java:11)
  at Main.f1(Main.java:7)
  at Main.main(Main.java:3)

.NET
using System;

public class Program
{
  public static void Main()
  {
    f1(1);
  }

  public static void f1(int i) {
    f2();
  }

  public static void f2() {
    f3();
  }

  public static void f3() {
    throw new Exception("oh no");
  }
}

Run-time exception (line 19): oh no

Stack Trace:

[System.Exception: oh no]
   at Program.f3() :line 19
   at Program.f2() :line 15
   at Program.f1(Int32 i) :line 11
   at Program.Main() :line 7

Swift
import Foundation

func f1(i: Int) {
    f2();
}

func f2() {
    f3();
}

func f3() {
    fatalError("oh no");
}

f1(i: 1);

main/main.swift:12: Fatal error: oh no
[1]    30171 trace trap  ./main

Zig
pub fn main() !void {
  f1(1);
}

fn f1(_: i32) void {
  f2();
}

fn f2() void {
  f3();
}

fn f3() void {
  @panic("oh no");
}

thread 22449779 panic: oh no
/Users/leighmcculloch/Code/zigtest/main.zig:14:3: 0x102242e4b in f3 (main)
  @panic("oh no");
  ^
/Users/leighmcculloch/Code/zigtest/main.zig:10:5: 0x1022416af in f2 (main)
  f3();
    ^
/Users/leighmcculloch/Code/zigtest/main.zig:6:5: 0x102240797 in f1 (main)
  f2();
    ^
/Users/leighmcculloch/Code/zigtest/main.zig:2:5: 0x102240777 in main (main)
  f1(1);
    ^
/opt/homebrew/Cellar/zig/0.13.0/lib/zig/std/start.zig:524:37: 0x1022409fb in main (main)
            const result = root.main() catch |err| {
                                    ^
???:?:?: 0x189b2a0df in ??? (???)
???:?:?: 0x9900ffffffffffff in ??? (???)
[1]    33104 abort      zig run main.zig

My main interest is mostly just readability. So adding more whitespace and line breaks would go a long way towards legibility.
e.g.
Event log (newest first):
0: [Diagnostic Event]
   topics:[error, Error(Auth, InvalidAction)],
   data:"escalating error to panic"
1: [Diagnostic Event]
   topics:[error, Error(Auth, InvalidAction)],
   data:["contract call failed", add, [[Policy, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4], [Temporary], [Admin]]]]
2: [Failed Diagnostic Event (not emitted)]
   contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM,
   topics:[error, Error(Auth, InvalidAction)], data:"caught error from function"
3: [Failed Diagnostic Event (not emitted)]
   contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM,
   topics:[error, Error(Auth, InvalidAction)],
   data:"escalating error to panic"
4: [Failed Diagnostic Event (not emitted)]
   contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM,
   topics:[error, Error(Auth, InvalidAction)],
   data:["Unauthorized function call for address", CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM]
5: [Diagnostic Event]
   topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), add],
   data:[Policy, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4], [Temporary], [Admin]]
6: [Diagnostic Event]
   contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM,
   topics:[fn_return, add],
   data:Void
7: [Contract Event]
   contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM,
   topics:[sw_v1, add, [Ed25519, [Bytes(a1738d72617d88f775693c9b9033d8bbb99d127ea9ac0f04940dd090350c5b4e)]]],
   data:[Ed25519, [Admin]]
8: [Diagnostic Event]
   topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), add],
   data:[Ed25519, [Bytes(a1738d72617d88f775693c9b9033d8bbb99d127ea9ac0f04940dd090350c5b4e)], [Persistent], [Admin]]
9: [Diagnostic Event]
   contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM,
   topics:[fn_return, add],
   data:Void
10: [Contract Event]
   contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2KM,
   topics:[sw_v1, add, [Secp256r1, [Bytes(f3f8d84ae2da5566c4a70e977c2a49888a66bb8c)]]],
   data:[Secp256r1, [Bytes(04a38ef5f2713768bd3480eeceaec2b10464a1f3b1ff0a3539c2cd2dd00a83a75d2c7b7e5fdbcfe6af5a602979c57fb44aeca0003cb9d3ae85d7c8d0e633d25ed6)], [Admin]]
11: [Diagnostic Event]
   topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000001), add],
   data:[Secp256r1, [Bytes(f3f8d84ae2da5566c4a70e977c2a49888a66bb8c)], [Bytes(04a38ef5f2713768bd3480eeceaec2b10464a1f3b1ff0a3539c2cd2dd00a83a75d2c7b7e5fdbcfe6af5a602979c57fb44aeca0003cb9d3ae85d7c8d0e633d25ed6)], [Persistent], [Admin]]

You could further break up arrays by comma if you wanted to but that would start to make stack traces very very long.

Idk if we have the ability to color anything but highlighting actual error messages would also be really nice.
e.g. from above these are really the meat of the error
"escalating error to panic"
"contract call failed"
"caught error from function"
"escalating error to panic"
"Unauthorized function call for address"

Great to see this being worked on, thank you! 😃
I have posted that example on twitter in Tomer's thread. Thank you again for your reply.
The task becomes very challenging if you are trying to do cross-contract calls. I understand a bit how that works (I helped polish the doc on that part during the last bounty) and once you get how to call another contract from yours, the next challenge becomes: how to read these errors.
Here is an example on my project. I am calling Soroban Domains to register a domain. If I deliberately change that line and use a non valid TLD (these 3 bytes write xlm)
https://github.com/tupui/soroban-versioning/blob/828bf95846fcdb5fa884ca5c7bb6f3ca73986017/contracts/versioning/src/lib.rs#L209
Then it will result in this panic.
Trace

/Users/tupui/.cargo/bin/cargo test --color=always --profile test --workspace --no-fail-fast --config env.RUSTC_BOOTSTRAP=\"1\" -- --format=json -Z unstable-options --show-output
Testing started at 23:43 ...
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running unittests src/lib.rs (target/debug/deps/versioning-0b6e8f3c06df1343)

HostError: Error(Contract, #4)

Event log (newest first):
   0: [Diagnostic Event] topics:[error, Error(Contract, #4)], data:"escalating error to panic"
   1: [Diagnostic Event] topics:[error, Error(Contract, #4)], data:["contract call failed", register, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, "tansu", [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARQG5], "github.com/file.toml", "2ef4f49fdd8fa9dc463f1f06a094c26b88710990", CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V]]
   2: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[error, Error(Contract, #4)], data:"caught error from function"
   3: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[error, Error(Contract, #4)], data:"escalating error to panic"
   4: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[error, Error(Contract, #4)], data:["contract call failed", set_record, [Bytes(74616e7375), Bytes(786c), CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, 31536000]]
   5: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[log], data:["VM call trapped with HostError", set_record, Error(Contract, #4)]
   6: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[error, Error(Contract, #4)], data:"escalating error to VM trap from failed host function call: fail_with_error"
   7: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[error, Error(Contract, #4)], data:["failing with contract error", 4]
   8: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[fn_call, Bytes(54ca65a58200bfffb708756d19fd134e1677063f85bb87e0c7a54abb480d375c), set_record], data:[Bytes(74616e7375), Bytes(786c), CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, 31536000]
   9: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[fn_return, record], data:Void
   10: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[fn_call, Bytes(54ca65a58200bfffb708756d19fd134e1677063f85bb87e0c7a54abb480d375c), record], data:[Record, Bytes(2324dc49faf83ad010cee02118b8244566e3f9065e94a2694a8f57e377f7275c)]
   11: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000006), register], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, "tansu", [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARQG5], "github.com/file.toml", "2ef4f49fdd8fa9dc463f1f06a094c26b88710990", CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V]
   12: [Diagnostic Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[fn_return, mint], data:Void
   13: [Contract Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[mint, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, "aaa:GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJXFF"], data:10000000000000000
   14: [Diagnostic Event] topics:[fn_call, Bytes(8011bbf4cdf04e5bc6ac886935b99aa4b2c0cabde133f9d7fb3e656799f0a896), mint], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM,<PHONE_NUMBER>0000000]
   15: [Diagnostic Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[fn_return, init], data:Void
   16: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000006), init], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK3IM
   17: [Diagnostic Event] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[fn_return, init], data:Void
   18: [Diagnostic Event] topics:[fn_call, Bytes(54ca65a58200bfffb708756d19fd134e1677063f85bb87e0c7a54abb480d375c), init], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4, 100, CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, 31536000, [Bytes(786c6d), Bytes(7374656c6c6172), Bytes(77616c6c6574), Bytes(64616f)]]
   19: [Diagnostic Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[fn_return, set_admin], data:Void
   20: [Contract Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[set_admin, GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJXFF, "aaa:GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJXFF"], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M
   21: [Diagnostic Event] topics:[fn_call, Bytes(8011bbf4cdf04e5bc6ac886935b99aa4b2c0cabde133f9d7fb3e656799f0a896), set_admin], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M
   22: [Diagnostic Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[fn_return, init_asset], data:Void
   23: [Diagnostic Event] topics:[fn_call, Bytes(8011bbf4cdf04e5bc6ac886935b99aa4b2c0cabde133f9d7fb3e656799f0a896), init_asset], data:Bytes(0000000161616100000000000000000000000000000000000000000000000000000000000000000000000004)

Backtrace (newest first):
   0: backtrace::backtrace::libunwind::trace
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/libunwind.rs:116:5
      backtrace::backtrace::trace_unsynchronized
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:66:5
   1: backtrace::backtrace::trace
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:53:14
   2: backtrace::capture::Backtrace::create
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:292:9
   3: backtrace::capture::Backtrace::new_unresolved
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:287:9
   4: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info::{{closure}}
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:293:37
   5: soroban_env_host::budget::Budget::with_shadow_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/budget.rs:972:21
   6: soroban_env_host::host::Host::with_debug_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:615:24
   7: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:290:13
   8: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error::{{closure}}
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:274:23
   9: soroban_env_host::budget::Budget::with_shadow_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/budget.rs:972:21
  10: soroban_env_host::host::Host::with_debug_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:615:24
  11: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:261:9
  12: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:767:26
  13: soroban_sdk::env::internal::reject_err::{{closure}}
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:52:23
  14: core::result::Result<T,E>::map_err
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
  15: soroban_sdk::env::internal::reject_err
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:52:9
  16: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:1667:13
  17: soroban_sdk::env::Env::invoke_contract
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:379:18
  18: versioning::VersioningClient::register
             at /Users/tupui/Documents/Code/soroban-versioning/contracts/versioning/src/lib.rs:56:1
  19: versioning::test::test
             at /Users/tupui/Documents/Code/soroban-versioning/contracts/versioning/src/test.rs:62:14
  20: versioning::test::test::{{closure}}
             at /Users/tupui/Documents/Code/soroban-versioning/contracts/versioning/src/test.rs:12:10
  21: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
thread 'test::test' panicked at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:768:9:
HostError: Error(Contract, #4)

Event log (newest first):
   0: [Diagnostic Event] topics:[error, Error(Contract, #4)], data:"escalating error to panic"
   1: [Diagnostic Event] topics:[error, Error(Contract, #4)], data:["contract call failed", register, [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, "tansu", [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARQG5], "github.com/file.toml", "2ef4f49fdd8fa9dc463f1f06a094c26b88710990", CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V]]
   2: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[error, Error(Contract, #4)], data:"caught error from function"
   3: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[error, Error(Contract, #4)], data:"escalating error to panic"
   4: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[error, Error(Contract, #4)], data:["contract call failed", set_record, [Bytes(74616e7375), Bytes(786c), CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, 31536000]]
   5: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[log], data:["VM call trapped with HostError", set_record, Error(Contract, #4)]
   6: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[error, Error(Contract, #4)], data:"escalating error to VM trap from failed host function call: fail_with_error"
   7: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[error, Error(Contract, #4)], data:["failing with contract error", 4]
   8: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[fn_call, Bytes(54ca65a58200bfffb708756d19fd134e1677063f85bb87e0c7a54abb480d375c), set_record], data:[Bytes(74616e7375), Bytes(786c), CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, 31536000]
   9: [Failed Diagnostic Event (not emitted)] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[fn_return, record], data:Void
   10: [Failed Diagnostic Event (not emitted)] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[fn_call, Bytes(54ca65a58200bfffb708756d19fd134e1677063f85bb87e0c7a54abb480d375c), record], data:[Record, Bytes(2324dc49faf83ad010cee02118b8244566e3f9065e94a2694a8f57e377f7275c)]
   11: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000006), register], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, "tansu", [CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARQG5], "github.com/file.toml", "2ef4f49fdd8fa9dc463f1f06a094c26b88710990", CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V]
   12: [Diagnostic Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[fn_return, mint], data:Void
   13: [Contract Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[mint, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M, CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM, "aaa:GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJXFF"], data:10000000000000000
   14: [Diagnostic Event] topics:[fn_call, Bytes(8011bbf4cdf04e5bc6ac886935b99aa4b2c0cabde133f9d7fb3e656799f0a896), mint], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOLZM,<PHONE_NUMBER>0000000]
   15: [Diagnostic Event] contract:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDR4, topics:[fn_return, init], data:Void
   16: [Diagnostic Event] topics:[fn_call, Bytes(0000000000000000000000000000000000000000000000000000000000000006), init], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK3IM
   17: [Diagnostic Event] contract:CBKMUZNFQIAL775XBB2W2GP5CNHBM5YGH6C3XB7AY6SUVO2IBU3VYK2V, topics:[fn_return, init], data:Void
   18: [Diagnostic Event] topics:[fn_call, Bytes(54ca65a58200bfffb708756d19fd134e1677063f85bb87e0c7a54abb480d375c), init], data:[CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCT4, 100, CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, 31536000, [Bytes(786c6d), Bytes(7374656c6c6172), Bytes(77616c6c6574), Bytes(64616f)]]
   19: [Diagnostic Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[fn_return, set_admin], data:Void
   20: [Contract Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[set_admin, GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJXFF, "aaa:GAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJXFF"], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M
   21: [Diagnostic Event] topics:[fn_call, Bytes(8011bbf4cdf04e5bc6ac886935b99aa4b2c0cabde133f9d7fb3e656799f0a896), set_admin], data:CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHK3M
   22: [Diagnostic Event] contract:CCABDO7UZXYE4W6GVSEGSNNZTKSLFQGKXXQTH6OX7M7GKZ4Z6CUJNGZN, topics:[fn_return, init_asset], data:Void
   23: [Diagnostic Event] topics:[fn_call, Bytes(8011bbf4cdf04e5bc6ac886935b99aa4b2c0cabde133f9d7fb3e656799f0a896), init_asset], data:Bytes(0000000161616100000000000000000000000000000000000000000000000000000000000000000000000004)

Backtrace (newest first):
   0: backtrace::backtrace::libunwind::trace
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/libunwind.rs:116:5
      backtrace::backtrace::trace_unsynchronized
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:66:5
   1: backtrace::backtrace::trace
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/backtrace/mod.rs:53:14
   2: backtrace::capture::Backtrace::create
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:292:9
   3: backtrace::capture::Backtrace::new_unresolved
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.74/src/capture.rs:287:9
   4: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info::{{closure}}
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:293:37
   5: soroban_env_host::budget::Budget::with_shadow_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/budget.rs:972:21
   6: soroban_env_host::host::Host::with_debug_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:615:24
   7: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::maybe_get_debug_info
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:290:13
   8: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error::{{closure}}
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:274:23
   9: soroban_env_host::budget::Budget::with_shadow_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/budget.rs:972:21
  10: soroban_env_host::host::Host::with_debug_mode
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:615:24
  11: soroban_env_host::host::error::<impl soroban_env_host::host::Host>::error
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host/error.rs:261:9
  12: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:767:26
  13: soroban_sdk::env::internal::reject_err::{{closure}}
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:52:23
  14: core::result::Result<T,E>::map_err
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
  15: soroban_sdk::env::internal::reject_err
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:52:9
  16: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:1667:13
  17: soroban_sdk::env::Env::invoke_contract
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:379:18
  18: versioning::VersioningClient::register
             at /Users/tupui/Documents/Code/soroban-versioning/contracts/versioning/src/lib.rs:56:1
  19: versioning::test::test
             at /Users/tupui/Documents/Code/soroban-versioning/contracts/versioning/src/test.rs:62:14
  20: versioning::test::test::{{closure}}
             at /Users/tupui/Documents/Code/soroban-versioning/contracts/versioning/src/test.rs:12:10
  21: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5

stack backtrace:
   0: rust_begin_unwind
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
   2: <soroban_env_host::host::Host as soroban_env_common::env::EnvBase>::escalate_error_to_panic
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-env-host-21.2.1/src/host.rs:768:9
   3: soroban_sdk::env::internal::reject_err::{{closure}}
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:52:23
   4: core::result::Result<T,E>::map_err
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/result.rs:854:27
   5: soroban_sdk::env::internal::reject_err
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:52:9
   6: <soroban_sdk::env::Env as soroban_env_common::env::Env>::call
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:1667:13
   7: soroban_sdk::env::Env::invoke_contract
             at /Users/tupui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/soroban-sdk-21.7.4/src/env.rs:379:18
   8: versioning::VersioningClient::register
             at ./src/lib.rs:56:1
   9: versioning::test::test
             at ./src/test.rs:62:14
  10: versioning::test::test::{{closure}}
             at ./src/test.rs:12:10
  11: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
  12: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Writing test snapshot file for test "test::test" to "test_snapshots/test/test.1.json".

Writing test snapshot file for test "test::test_utils" to "test_snapshots/test/test_utils.1.json".
error: test failed, to rerun pass `--lib`
error: 1 target failed:
    `--lib`

Process finished with exit code 101

There are a few things here. First the stacktrace is too long 😅 It's showing me too much of what happened with previous calls I made running the test suite. It took me a while, too long I care to admit, to actually understand that and it was not relevant to my issue. Removing all that, we are left with 10 items, still a bit too long and there is quite some repetition due to this escalation in the stack. What you might eventually start to notice is the repetition of Error(Contract, #4)]. It took me a while to also get what this was: the error code thrown by Soroban Domains contract itself. But what is this 4. Here you have to find the source code to finally get to it (can also not be that obvious to find):
https://github.com/Creit-Tech/sorobandomains-sc/blob/main/contracts/registry/src/errors.rs
And here we have it in the enum: UnsupportedTLD = 4. (Getting the correct parameters is another story in itself 😅 same with making tests.)

I am not sure how all that is possible, but if there was a way to resurface better the meaning of error codes, that would be really helpful. Then, adding colors as @kalepail suggest could be super helpful to separate sections. This could also be accomplished by splitting a bit more the output of the trace. I guess in some cases you want this super verbose output and my case is "too simple". But that's the thing to me simple cases like these should be simple to debug and for now it's hard.
Hope that helps 😃

Here you have to find the source code to finally get to it (can also not be that obvious to find):
https://github.com/Creit-Tech/sorobandomains-sc/blob/main/contracts/registry/src/errors.rs
And here we have it in the enum: UnsupportedTLD = 4.

If you have the .wasm for the contract, or you know it's address on chain, you can lookup the error using the specification without the source.
$ stellar contract info interface --network testnet --id CADDH3WW3EHDEUY4HIQUAZHRPCFQFL4MZIEZBFUIIHJAXZNLQWVC6DV4
...
pub enum ContractErrors {
    UnexpectedError = 0,
    AlreadyStarted = 1,
    RecordAlreadyExist = 2,
    InvalidDuration = 3,
    UnsupportedTLD = 4,
    RecordDoesntExist = 5,
    InvalidDomain = 6,
    ExpiredDomain = 7,
    InvalidParent = 8,
    OutdatedSub = 9,
    InvalidTransfer = 10,
    InvalidOfferAmount = 11,
    OutdatedOffer = 12,
    OfferDoesntExist = 13,
}

@Ifropc Maybe we should add another sub-command to contract info, such as contract info errors, that just outputs a json mapping of errors to error codes 🤔

Thanks, I did not know that command 👍 That will help in such cases. Might be more tricky if the underlying contract does not properly validate inputs and would break (I did not check, so just talking hypothetically here.)

I am not sure if this is the right place, but I found another interesting case with some obscure error message.
If you are using storage, at compile time it does not tell you if you are using the correct type to store and update values.
e.g. with this structure
#[contracttype]
pub struct Proposal {
    ...
}

#[contracttype]
pub struct Dao {
    pub proposals: Vec<Proposal>,
}

#[contracttype]
pub enum ProjectKey {
    ...
    DaoTotalProposals(Bytes),
}

I was wrongly updating an entry of ProjectKey::Dao with Proposal although I had first set the value to be Dao
env.storage()
    .persistent()
    .set(&ProjectKey::Dao(project_key, page), &proposal)

And this gives this error
differing host map and output slice lengths when unpacking map to slice

(Additionally it was also not pointing directly to the  problematic line but I could find that using RustRover's debugger.)
This bugged me for a while. Here I got some luck with Stella 😅
This specific error occurs when trying to retrieve data from storage where there's a mismatch between the data structure you're trying to deserialize into and the actual data stored.
...
    // Make sure this matches exactly what was stored
    // Including all fields and their types

Stella's full response
Understanding the Storage Get Error
This specific error occurs when trying to retrieve data from storage where there's a mismatch between the data structure you're trying to deserialize into and the actual data stored.
Common Causes

Data Type Mismatch

// If you stored data as one type
#[derive(Clone)]
#[contracttype]
pub struct OldDao {
    field1: String,
    field2: i32,
}

// But trying to retrieve as another type
#[derive(Clone)]
#[contracttype]
pub struct NewDao {
    field1: String,
    field2: i32,
    field3: Vec<String>, // Added field
}

How to Fix

Verify Your Data Structure

#[derive(Clone)]
#[contracttype]
pub struct Dao {
    // Make sure this matches exactly what was stored
    // Including all fields and their types
}

// When retrieving
let dao: Dao = env.storage().persistent()
    .get(&DataKey::Dao(project_key, page))
    .unwrap_or_else(|| panic!("Not found"));

Check if Data Exists

// Safe retrieval with error handling
if let Some(dao) = env.storage().persistent().get(&DataKey::Dao(project_key, page)) {
    // Data exists and matches the type
} else {
    // Handle case where data doesn't exist
}

Best Practices

Always keep track of your contract's data structure versions
When updating contracts, ensure compatibility with existing stored data
Consider implementing migration strategies for data structure changes

If the error persists, try:

Checking the exact type definition used when the data was stored
Verifying the storage key structure matches what was used for storing
Using debug prints to confirm the data exists in storage

Sources:
https://github.com/stellar/rs-soroban-sdk/pull/831
What does the error symbol not found in slice of strs indicate?
https://github.com/stellar/rs-soroban-sdk/pull/787
Contract (Soroswap) Integration

I can see how that error message didn't point at the issue at all. This is, in general, the issue with errors within host functions, they have no context where they're being used and for what. So in this case that host function was being used for custom type struct unpacking, but the context about that is in the sdk, but the error is being raised and the contract is being terminated before returning back to the contract where the context is.


using visual storyshots snapshots with static build

If you are reporting a bug or requesting support, start here:
Bug or support request summary
I'm trying to integrate the visual storyshots snapshots, using the static build option. according to the documentation (https://github.com/storybooks/storybook/tree/master/addons/storyshots#specifying-the-storybook-url), this is can be done by providing "{storybookUrl: 'file:///path/to/my/storybook-static'}".
No matter what relative path i'm trying to use, the test fail with :
ERROR WHILE CONNECTING TO ./storybook-static/iframe.html?selectedKind=AppHeader&selectedStory=AppHeader, did you start or build the storybook first ? A storybook instance should be running or a static version should be built when using image snapshot feature.
I tried setting the path relative to the actual Storyshot.test.js, relative to the package.json. neither work.
the file structure is:
-.storybook/
-src/
--components/
--storyshots.test.js
-storybook-static/ (create with 'npm run build-storybook')
-package.json
...other folders...
the storyshots.test.js is :
import initStoryshots, { imageSnapshot } from '@storybook/addon-storyshots';

initStoryshots({ suite: 'Image storyshots', test: imageSnapshot({ storybookUrl: './storybook-static' }) });

tried to replace the storybookUrl with '../storybook-static'
Please specify which version of Storybook and optionally any affected addons that you're running

@storybook/react 3.3.15
@storybook/addon-storyshots 3.4.3

Affected platforms

react JS
macOS

Screenshots / Screencast / Code Snippets (Optional)
// code here

NM. realized I should use the full path.
now it works


Make time move along at the same rate in all threads during headless execution

RFC. Primarily, this should fix the osu!-side macOS test failures when running under MultiThread execution mode. This will also likely fix other unexplainable flaky tests.
Unfortunately, I don't think this is or I can't reason as to why it would be related to the clock running backwards (https://github.com/ppy/osu/issues/26879), as I'd hoped to find :(
Reproduction:
Local osu!-framework checkout with:
diff --git a/osu.Framework/Threading/AudioThread.cs b/osu.Framework/Threading/AudioThread.cs
index 171f43280..4debaad82 100644
--- a/osu.Framework/Threading/AudioThread.cs
+++ b/osu.Framework/Threading/AudioThread.cs
@@ -65,6 +65,8 @@ private void onNewFrame()
                     m.Update();
                 }
             }
+
+            System.Threading.Thread.Sleep(200);
         }

         internal void RegisterManager(AudioManager manager)

Run test TestSceneCatchModNoScope.TestVisibleDuringBreak.
Investigation
As far as I could deduce, this is caused by the audio thread running much slower than the update thread.
FastClock increments CurrentTime by 33ms every time it is referenced. In headless execution, this happens once per frame, as mandated by the FramedClock wrapping it.
https://github.com/ppy/osu-framework/blob/4f516283dbe9e8b079e1b26783624ecab8a30546/osu.Framework/Platform/HeadlessGameHost.cs#L71-L92
osu! tests use the test scene's clock (which is the framed FastClock from above) as the reference clock for the beatmap, allowing gameplay tests to execute at non-realtime speeds:
https://github.com/ppy/osu/blob/95783bd6c2543f15d71f89c6a3469a0d0fcfaba6/osu.Game/Tests/Visual/OsuTestScene.cs#L321-L322
The TrackVirtualManual referencing that clock is only updated from the audio thread.
https://github.com/ppy/osu/blob/95783bd6c2543f15d71f89c6a3469a0d0fcfaba6/osu.Game/Tests/Visual/OsuTestScene.cs#L497-L518
So, the failure case seems to be as follows:

The update thread is running much faster than the audio thread (could be CI runner resource exhaustion/etc - these failures started coming up after the runner was moved to ARM64). I've observed the imbalance up to 2 orders of magnitude.
This results in the FastClock updating very frequently, but the TrackVirtualManual updating very _in_frequently.
When the TrackVirtualManual finally updates, it skips forward several seconds in execution, which gameplay also follows.
Because of the skip, certain test steps aren't executed fast enough (only executed every 200ms) while their expected gameplay state has been skipped.

Using TestVisibleDuringBreak as an example, here's a visual simulation. Only the audio thread is being paused here (for 4s):
https://github.com/ppy/osu-framework/assets/1329837/15d2f41e-e8a3-451b-a4e4-a15f2ab4140f
This also makes it intuitive why single-threaded execution is unaffected.
Fix
I would say that the fix here is a little bit of a workaround. We're preventing the threads from getting too far out-of-sync time-wise without limiting their run rate, matching a little bit closer to reality.

Test fails here look concerning. Framework for one has been 99% green on tests thus far, so I am spooked. Could be a red herring, though.

Yeah, your spook is shared.

The changes look fine to me


Update two_sp_queue_traffic_test.go

Internal test result: b/269796820

/gcbrun

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 57.081%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1181

Relevant Lines:
2069

💛  - Coveralls


Fork and fix the typeahead code to fix the tab searchbox behavior.

the typeahead library hasn't been updated in years, but stackoverflow pointed me to the _onTabKeyed function.  This patch has the source (mit license) and a minified version of it.
The behavior here now is that tab is the same as down arrow.

The CDN version doesn't have the patch to change the tab key behavior that actually deals with the issue.  There are other, more invasive, changes like switching away from the typeahead library, which we can do separately (and probably should consider).


Batch: computeResources.instanceRole is an instance profile

It's not an IAM role (the API parameter name in Batch is a misnomer).
Validation by matching against known role ARNs will always fail.
Scan the known instance profile ARNs instead.
Relevant part of Batch docs:

instanceRole (string) -- [REQUIRED]
The Amazon ECS instance profile applied to Amazon EC2 instances in a compute environment. You can specify the short name or full Amazon Resource Name (ARN) of an instance profile. For example, ecsInstanceRole or arn:aws:iam::<aws_account_id> :instance-profile/ecsInstanceRole  . For more information, see Amazon ECS Instance Role in the AWS Batch User Guide .

Coverage decreased (-0.1%) to 94.065% when pulling 624dafcb5cdec8b0de78f2998cdf5862d85b82aa on kislyuk:patch-2 into d86852bfa0fd79c62b8a5931d12d2c8a25b47833 on spulec:master.


PHP-Proxy <= 5.1.0 - The decrypt key is flawed and cause the vulnerability of LFI

We discovered the PHP-Proxy str_rot_pass encrypt function is flawed. Despite the user change the default key, the remote attacker can easily decrypt the key and cause the vulnerability of Local File Inclusion.

Detailed steps and sample payload：
https://github.com/0xUhaw/CVE-Bins/tree/master/PHP-Proxy
We suggest that the encryption rules should be strengthened because the logic of decryption is too easy.

Is there anything that regular users can do now other than simply stop using the proxy?

Since this is the encrypt key problem, this should be fixed by the official...
If it is a problem for LFI, you can disable curl file protocol.


Composability of Cycle add-ons as wrapper functions

This is not quite a bug report, more like a token of something to figure out when things are more mature.
I'm wondering about the composability of Cycle add-ons which arrive as a function which wraps the application main function. Once an application uses several of those, it needs to choose what order to wrap them. Wrapping does not seem to compose as well as adding drivers.
The specific case I hit was with onionify and cyclejs-modal:
https://github.com/cyclejs-community/cyclejs-modal
both of which arrive as a function to wrap around the application main function.
I ended up with this wrapping order:
const main = modalify(onionify(App));

... which yields both libraries working, with the caveat that onion state is not available within a component instantiated by modalify.  This requires a workaround for state, carrying state needed for the modal by some means other than onion. (I briefly dabbled with a global variable, the allure of the dark side is sometimes strong...)
If I wrap them the other way, onion state is available inside the component instantiated by modalify - but modalify fails to work, for reasons I did not debug.
I would guess the fundamental challenge is: I'm using two libraries both of which expect to be the "outermost" wrapper function. Staring at the source code of both things, it's not clear to me what could be done to either to make their functionality mutually available to each other.

If I wrap them the other way, onion state is available inside the component instantiated by modalify - but modalify fails to work, for reasons I did not debug.

@kylecordes First I'd try to figure out what went wrong with that approach. Note than when doing onionify(foo), the foo is written in a way that assumes that sources.onion is available, so what onionify() is doing is just building that sources.onion and passing it to the foo. So replace foo with modalify(App) and it means modalify(App) should be written in a way that assumes sources.onion is available.

@staltz It seems likely I could dig through and figure it out, the source is not very long:
https://github.com/cyclejs-community/cyclejs-modal/blob/master/src/modalify.ts
... When I get a chance I will fork both, and whatever bits of debugging I need, and track it down.
More broadly, it seems like a composeability challenge. Each add-on is written and documented and tested assuming it will be the outermost wrapper. From the point of view of each, the course of action is to put it on the outside and then go debug the other add-on to figure out why it doesn't work when it's not on the outside.
Is there any way to get traction on the broader challenge? To consume a set of Cycle add-ons, and have them compose out-of-the box? It seems like trying each permutation of nesting order and debugging why a particular combination of things doesn't work together when composed in a certain order, would not scale very well to n available add-ons of which application consumes k. I've forgotten the exact formula for permutations P(n,k), but it involves factorials, and gets ugly fast.
Maybe it will turn out that there is some set of rules and way of testing for those rules, that a Cycle add-on could follow if it needs to ship as a wrapper function, such that it can be expected to compose in a predictable way with other wrapper functions?

You basicly have to compose them based on the features you want where. If you want state in a modal, you would have to put the state around the modal. I have no idea why this dies not wirk, please open an issue for that.


Lambda can't find NodeJS layer packages during compilation

Expected behavior:
I ran the Claudia update command with --layers tag for deployment purposes. The layer contains the common node js packages, as defined here: https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-path

I am referring to one of the dependencies ('mssql' included in the layer) from my index js file.

What actually happens:
I get the following error:
validating package
Error: Cannot find module 'mssql'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:580:15)
at Function.Module._load (internal/modules/cjs/loader.js:506:25)
at Module.require (internal/modules/cjs/loader.js:636:17)
at require (internal/modules/cjs/helpers.js:20:18)

Steps to reproduce the problem:

Simply create a nodejs layer as described here: https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-path and Deploy it
Create a new lambda (index.js file) and refer to any of the packages installed in Nodejs layer.
Try deploying the lambda using Claudia create or Claudia update command

if this fails during claudia packaging, there are two options:

install mysql as an optional dependency  , then use --no-optional-dependencies when you deploy with claudia. it will not bundle the dependency in the package, but it will pass validation
lazy-load the required package (not in the file headers, but in a function on first use) to use layer dependencies that are not bundled with your code. alternatively, you can


add SofaRejectedExecutionHandler for  user-customized thread pool

Motivation:
The bizExecutor of all servers (TripleServer, httpServer, BoltServer) are configured with SofaRejectedExecutionHandler for exception handling and log processing， but the user-customized thread pool is missing.

Summary by CodeRabbit

New Features

Introduced a custom handler for managing rejected tasks in the thread pool, improving task execution control.

Tests

Added a new test to verify the functionality of the rejected execution handler in the thread pool.

@bohrqiu Thank for your pr. Pls run mvn clean compile before git commit.

@EvenLjj done

@bohrqiu It's still the same problem.

@EvenLjj oh sorry, i got it . i had format the code and run  mvn clean install -Pci-install -B -U -e && bash ./tools/check_format.sh


when i destoryed the sprite

aser.js:171936 Uncaught TypeError: Cannot read properties of undefined (reading 'body')
at World.remove (phaser.js:171936:1)
at Object.destroy (phaser.js:179463:1)
at Project.onCompose (game.js:479:1)
at Tween.onComplete (game.js:310:1)
at Tween.dispatchTweenEvent (phaser.js:58162:1)
at Tween.nextState (phaser.js:57743:1)
at Tween.update (phaser.js:58103:1)
at TweenManager.update (phaser.js:178102:1)
at EventEmitter.emit (phaser.js:1694:1)
at Systems.step (phaser.js:41844:1)
at SceneManager.update (phaser.js:84646:1)
at Game.step (phaser.js:137314:1)
at TimeStep.step (phaser.js:75507:1)
at step (phaser.js:75715:1)
r

Code sample please.

Thanks for opening this issue. As much as we'd love to help you, we need a fully working code sample to do so. Please provide one and then we'll re-open this issue and look at resolving it for you if possible.


Using fix:true overwrites the file with an error if it fails.

If an error prevents the fix from completing, like if there is a missing bracket, the file is overwritten with the error.
I cannot get the task to fail before the file is written.

Verified I'm seeing this too.  The fix flag doesn't seem to do anything.

This is actually something I'm not sure how to fix. I'll investigate it later. Help appreciated.

Just thinking out loud:
I would say you need to emit an error, and instruct the user to always listen for the error so they can emit an end to the process before writing it to the file.
This may require splitting the processing and writing to 2 different functions so the user can bail before its written. I think you probably could do a "bailOnError" flag or something?


Enable win

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@isuruf, note that upstream essentially recommends not to use cmake anymore: https://github.com/conda-forge/libflint-feedstock/pull/32#issuecomment-2255561465

Cmake is still recommended for windows. See https://github.com/albinahlback/flint/blob/main/doc/source/building.rst#quick-start

@isuruf It seems the build failed when it was merged to main. https://github.com/conda-forge/libflint-feedstock/commits/main/


How to use vue single file component?

I am building a large system with vue and vuex. This module system doesn't have "assets" or any directory where I can put my front-end logics in here.
How can I implements this feature?
Thanks

I would think of two possibilities.

You could use the "global" assets. That's how I always did it
You could configure your filesystem to have multiple discs for a more "scoped" solution.

I'm closing this question for now. Feel free to reopen it.


Is there any plan to use bson crate?

Since bson crate have all functionalities that you implemented in polodb_bson crate. And it have additional features such as serde , chrono. Do you have a plan to use bson crate in this project? If you like, then I can work on it. Because I am working on a project that need to use mongodb and polodb in same time.

Hello, thanks for your attention.
polodb_bson's name may mislead you that its data is serialized as bson(it was).
Currently, it's data is serialized as msgpack using rmp. Because I think msgpack performs better.
If you think using that bson crate can help in your project, I will gladly accept your revisions. But I want to remind you that this is a breaking change.

@vincentdchan Ok. I got it. I do not want to use bson format. But I want to use the serde as a serialization library for PoloDB.

If you want to contribute, you can ask any question directly. I will reply ASAP.

PoloDB is planned to support serde. I will work on this feature.

Using the bson from mongodb maybe a good choice. I will give it a try.


Need documentation on custom events

I hard a hard time finding info on custom events. Did find what I was looking for at https://github.com/aspnet/Blazor/issues/236#issuecomment-372240986, you would perhaps consider incorporating this in this page?
Thank you for your consideration.

Dokumentoplysninger
⚠ Undlad at redigere denne sektion. Det er påkrævet til docs.microsoft.com ➟ GitHub-problemlinkning.

ID: be4c4d0c-149c-bde1-c7fa-f082916390ca
Version Independent ID: 9d945996-ad02-bd4b-58ea-c465cc5cc74c
Content: Create and use ASP.NET Core Razor components
Content Source: aspnetcore/blazor/components.md
Product: aspnet-core
Technology: aspnetcore-blazor
GitHub Login: @guardrex
Microsoft Alias: riande

I like it ... thanks @harleydk. We'll get this scheduled.

Not sure this is a custom event or not but I can't figure how to refresh the parent state from a complex child. For example, the child is a collection html controls with local onchange events in the child. But once the child event has fired, it needs to invoke the child component's onchange to send a notification to the parent so it can refresh state.
Parent

MyChild

When MylocalText1Changed is called, how do we invoke a call back to the parent at the component level?

@VR-Architect We've been discussing that a bit on https://github.com/aspnet/AspNetCore.Docs/issues/13539. Follow along and chat with the devs on that issue for now. I'm still groking the cross-component event binding myself, but I'm hampered a bit by 🏃 lots of unrelated work 🏃 at the moment. I hope to be able to spend some time with those concepts within a week and see what can be done on that issue with the docs to clarify things further.

Thanks @guardex I think I solved my issue with this request to add an example to this doc to you. I provided an example. Please feel free to use and enhance :)
https://github.com/aspnet/AspNetCore.Docs/issues/13651

Back to the original ask: This seems to be a point-in-time problem when this was opened. Doesn't EventCallback cover this?

Probably does. I haven't had time to experiment with Blazor since August, likely won't for some time to come. Might as well close this one up, unless you'd like to keep it open?

Let’s close for now. If the latest docs still pose a problem, open a new issue later using the This Page feedback form/button at the bottom of the topic.


Clean up and handle min_periods properly in rolling of Series and Frame

Avoid to use lag which refers the value in the offset. min_periods refers the number of values.
Use row_number instead to count the number of values properly as many as min_periods.
Match the documentation with Expanding
Fix ordering of defined APIs to match with Expanding.

cc @itholic since you're working on this. Let's match to Expanding implementation so that we can deduplicate both codes at _RollingAndExpanding.

Codecov Report

Merging #1025 into master will decrease coverage by 2.46%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master    #1025      +/-   ##
==========================================
- Coverage   94.92%   92.45%   -2.47%
==========================================
  Files          34       34
  Lines        6699     6697       -2
==========================================
- Hits         6359     6192     -167
- Misses        340      505     +165

Impacted Files
Coverage Δ

databricks/koalas/window.py
92.96% <90.9%> (-0.08%)
:arrow_down:

databricks/koalas/usage_logging/__init__.py
24.54% <0%> (-72.73%)
:arrow_down:

databricks/koalas/usage_logging/usage_logger.py
50% <0%> (-50%)
:arrow_down:

databricks/koalas/__init__.py
78.72% <0%> (-8.52%)
:arrow_down:

databricks/conftest.py
92% <0%> (-6%)
:arrow_down:

databricks/koalas/utils.py
95% <0%> (-3.13%)
:arrow_down:

databricks/koalas/frame.py
93.98% <0%> (-2.36%)
:arrow_down:

databricks/koalas/groupby.py
89.34% <0%> (-2.05%)
:arrow_down:

databricks/koalas/namespace.py
85.75% <0%> (-1.55%)
:arrow_down:

databricks/koalas/plot.py
93.33% <0%> (-0.96%)
:arrow_down:

... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 21cff0f...40d6bd0. Read the comment docs.

@HyukjinKwon okay i got it :)

I'm merging it. Still I am touching this code ..


Setting OPCPublisher PublishedNodes configuration publishing interval more than 2 minutes failed?

Not really this complicated but a direct question to those who had experience it.
I don't know if I am the only one that had encountered this.
The version I am using is the 2.4.1 and not the latest since it has this problem with symlinking the appdata to an external folder so I can put my publishednodes config without going inside a docker.
Correct me if I am wrong and please do have a suggestions.

Solve my own issue:
commandline timeout should exceed more than your publishednodes published interval.


client-side throttling, not priority and fairness

What version of descheduler are you using?
descheduler version: 0.25.2
Does this issue reproduce with the latest release?
yes
Which descheduler CLI options are you using?
cmdOptions:
    v: 3

Please provide a copy of your descheduler policy config file
➜ kgcm descheduler -o yaml
apiVersion: v1
data:
  policy.yaml: |
    apiVersion: "descheduler/v1alpha1"
    kind: "DeschedulerPolicy"
    evictFailedBarePods: true
    evictLocalStoragePods: true
    ignorePvcPods: false
    maxNoOfPodsToEvictPerNamespace: 10
    maxNoOfPodsToEvictPerNode: 10
    strategies:
      LowNodeUtilization:
        enabled: true
        nodeFit: true
        params:
          namespaces:
            exclude:
            - mysql57
            - influxdb
            - mongodb
            - etcd
            - prometheus
            - monitoring
            - ops
            - metrics-server
          nodeResourceUtilizationThresholds:
            targetThresholds:
              cpu: 70
              memory: 70
              pods: 50
            thresholds:
              cpu: 40
              memory: 40
              pods: 20
      PodLifeTime:
        enabled: true
        params:
          namespaces:
            include:
            - mysql57
            - influxdb
            - mongodb
            - etcd
            - utils
          podLifeTime:
            maxPodLifeTimeSeconds: 86400
      RemoveDuplicates:
        enabled: false
        nodeFit: true
      RemovePodsHavingTooManyRestarts:
        enabled: true
        params:
          podsHavingTooManyRestarts:
            includingInitContainers: true
            podRestartThreshold: 20
      RemovePodsViolatingInterPodAntiAffinity:
        enabled: true
        nodeFit: true
      RemovePodsViolatingNodeAffinity:
        enabled: true
        nodeFit: true
        params:
          nodeAffinityType:
          - requiredDuringSchedulingIgnoredDuringExecution
      RemovePodsViolatingNodeTaints:
        enabled: true
        nodeFit: true
      RemovePodsViolatingTopologySpreadConstraint:
        enabled: true
        nodeFit: true
        params:
          includeSoftConstraints: false
kind: ConfigMap

What k8s version are you using (kubectl version)?
kubectl version Output
➜ k version
Client Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.6-eks-7d68063", GitCommit:"f24e667e49fb137336f7b064dba897beed639bad", GitTreeState:"clean", BuildDate:"2022-02-23T19:32:14Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"23+", GitVersion:"v1.23.13-eks-fb459a0", GitCommit:"55bd5d5cb7d32bc35e4e050f536181196fb8c6f7", GitTreeState:"clean", BuildDate:"2022-10-24T20:35:40Z", GoVersion:"go1.17.13", Compiler:"gc", Platform:"linux/amd64"}

What did you do?
I started getting the following log in the descheduler pod
I1220 20:34:19.947974       1 request.go:533] Waited for 194.413528ms due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:443/api/v1/namespaces/oprs/pods
I1220 20:34:20.147238       1 request.go:533] Waited for 195.264831ms due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:443/api/v1/namespaces/ops/pods
I1220 20:34:20.347929       1 request.go:533] Waited for 189.438292ms due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:443/api/v1/namespaces/opsgenie/pods

How to get rid of them?

That error is coming from the kube client/api server, not specifically a descheduler issue. Maybe we can update our client config though to avoid that.
Just curious, what interval are you running the descheduler at? Wondering if that is causing the throttling.

@damemi I always get it regardless of the period. I had it */15 * * * *, and now 0 0 * * SUN but still do see these messages.
It seems this can be fixed at the client level, I faced similar issue using kubernetes-event-exporter
https://github.com/resmoio/kubernetes-event-exporter/issues/27
and the fix was by adding the folllowing to the config
        config:
          logLevel: error
          logFormat: json
          throttlePeriod: 10  <----------------THIS
          maxEventAgeSeconds: 10 <----------------THIS
          kubeQPS: 60 <----------------THIS
          kubeBurst: 60 <----------------THIS
          receivers:
            - name: "dump"
              file:
                path: "/dev/stdout"
                layout:
                  message: "{{ printf "{{ .Message }}" }}"
                  reason: "{{ printf "{{ .Reason }}" }}"
                  type: "{{ printf "{{ .Type }}" }}"
                  count: "{{ printf "{{ .Count }}" }}"
                  kind: "{{ printf "{{ .InvolvedObject.Kind }}" }}"
                  name: "{{ printf "{{ .InvolvedObject.Name }}" }}"
                  namespace: "{{ printf "{{ .Namespace }}" }}"
                  component: "{{ printf "{{ .Source.Component }}" }}"
                  host: "{{ printf "{{ .Source.Host }}" }}"

I would be interested in implementing this unless you wanted to take it @dmitry-mightydevops ?

@a7i I don't have golang experience enough to take it on at this time, sorry :(

hey @damemi , how long does it take usually for a new release?
Because I'm facing the same issue and couldint find an container image that includes the PR.
@a7i Are there any other workarounds using v0.26.0?

@5cat We align with Kubernetes releases which is ~April: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.27


Make HLL gob-serializable

made everything but Hasher gob-serializable.

This looks great! Could you change the travis.yml to use more recent go versions (maybe 1.5, 1.4 and 1.3) and see if it passes the test?

Please have a another look.

Perfect! Any last changes before a merge?

I think it is good to go. Thanks!


python310Packages.fpyutils: 2.2.0 -> 2.2.1

Description of changes
https://blog.franco.net.eu.org/software/CHANGELOG-fpyutils.html#221---2022-10-27

Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 198106 run on x86_64-linux 1

5 packages built:

python310Packages.fpyutils
python310Packages.md-toc
python310Packages.mypy-boto3-builder
python39Packages.fpyutils
python39Packages.md-toc


[Snyk] Security upgrade react-scripts from 3.4.4 to 5.0.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

services/web/package.json
services/web/package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

220/1000  Why? Confidentiality impact: High, Integrity impact: Low, Availability impact: Low, Scope: Unchanged, Exploit Maturity: Proof of Concept, User Interaction (UI): None, Privileges Required (PR): None, Attack Complexity: Low, Attack Vector: Network, EPSS: 0.00043, Social Trends: No, Days since published: 0, Reachable: No, Transitive dependency: Yes, Is Malicious: No, Business Criticality: High, Provider Urgency: High, Package Popularity Score: 99, Impact: 7.84, Likelihood: 2.81, Score Version: V5
Server-side Request Forgery (SSRF) SNYK-JS-IP-6240864
Yes
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Commit messages

Package name: react-scripts
    The new version differs by 238 commits.

221e511 Publish
6a3315b Update CONTRIBUTING.md
5614c87 Add support for Tailwind (#11717)
657739f chore(test): make all tests install with `npm ci` (#11723)
20edab4 fix(webpackDevServer): disable overlay for warnings (#11413)
69321b0 Remove cached lockfile (#11706)
3afbbc0 Update all dependencies (#11624)
f5467d5 feat(eslint-config-react-app): support ESLint 8.x (#11375)
e8319da [WIP] Fix integration test teardown / cleanup and missing yarn installation (#11686)
c7627ce Update webpack and dev server (#11646)
f85b064 The default port used by `serve` has changed (#11619)
544befe Update package.json (#11597)
9d0369b Fix ESLint Babel preset resolution (#11547)
d7b23c8 test(create-react-app): assert for exit code (#10973)
1465357 Prepare 5.0.0 alpha release
3880ba6 Remove dependency pinning (#11474)
8b9fbee Update CODEOWNERS
cacf590 Bump template dependency version (#11415)
5cedfe4 Bump browserslist from 4.14.2 to 4.16.5 (#11476)
50ea5ad allow CORS on webpack-dev-server (#11325)
63bba07 Upgrade jest and related packages from 26.6.0 to 27.1.0 (#11338)
960b21e Bump immer from 8.0.4 to 9.0.6 (#11364)
134cd3c Resolve dependency issues in v5 alpha (#11294)
b45ae3c Update CONTRIBUTING.md

See the full diff

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Server-side Request Forgery (SSRF)

Checkmarx One – Scan Summary & Details – 0780b85e-a38d-464d-ad07-b8b90bbc23f3
Fixed Issues

Severity
Issue
Source File / Package

CVE-2020-28469
Npm-glob-parent-3.1.0

CVE-2020-28477
Npm-immer-1.10.0

CVE-2021-23337
Npm-lodash.template-4.5.0

CVE-2021-23382
Npm-postcss-7.0.21

CVE-2021-23424
Npm-ansi-html-0.0.7

CVE-2021-23436
Npm-immer-1.10.0

CVE-2021-3757
Npm-immer-1.10.0

CVE-2021-42740
Npm-shell-quote-1.7.2

CVE-2022-24771
Npm-node-forge-0.10.0

CVE-2022-24772
Npm-node-forge-0.10.0

CVE-2022-3517
Npm-minimatch-3.0.4

CVE-2022-37599
Npm-loader-utils-1.2.3

CVE-2022-37601
Npm-loader-utils-1.2.3

CVE-2022-37603
Npm-loader-utils-1.2.3

CVE-2023-26136
Npm-tough-cookie-2.5.0

CVE-2023-46234
Npm-browserify-sign-4.2.0

CVE-2024-22233
Maven-org.springframework:spring-core-5.3.13

Cx347a3da7-ba99
Npm-node-forge-0.10.0

Cxc7705965-e0f0
<EMAIL_ADDRESS>

CVE-2021-23364
Npm-browserslist-4.10.0

CVE-2021-23368
Npm-postcss-7.0.21

CVE-2021-24033
Npm-react-dev-utils-10.2.1

CVE-2022-0122
Npm-node-forge-0.10.0

CVE-2022-24773
Npm-node-forge-0.10.0

CVE-2023-26159
Npm-follow-redirects-1.15.2

CVE-2023-28155
Npm-request-2.88.2

Cx366abb53-9fde
Npm-es5-ext-0.10.62

Cxbd6f2b91-dd38
Npm-debug-4.1.1


Mongoid 6 compatibility

Are there plans to provide Mongoid 6 compatibility?

Would love a PR!

see https://github.com/mongoid/mongoid-shell/pull/11


ACM:8806 | feat: support clusterOSImage for vSphere Disconnected

Related issue: https://issues.redhat.com/browse/ACM-8806

/hold