Add job_id/project_id to adapter response to enable easy job linking

resolves #92
Description
Adding job_id / project_id from the job executed by BQ to add a clean link to explore the runtime in the BQ UI.
Practically, it adds a link in your -d runs such as:
13:28:11.169553 [debug] [Thread-1 (]: BigQuery adapter: Job details accessible at https://console.cloud.google.com/bigquery?project=<project>&j=<jobId>&page=queryresults

Checklist

[x] I have signed the CLA
[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[x] I have updated the CHANGELOG.md and added information about my change to the "dbt-bigquery next" section.

It's a bit hidden in the massive debug logs.
It also doesn't log the job link for failing queries (syntax errors raised via handle_error).
Furthermore logging the link separately leads to interleaved output with multiple threads.
Here are WIP patches we're using atm.
Immediately clickable query debugging is a major productivity boost.
https://github.com/7Learnings/dbt-core/tree/v1.2.0+bigquery-job-links.1 (add job link to adapter response message)
https://github.com/7Learnings/dbt-bigquery/tree/v1.2.0+bigquery-job-links.1 (log adapter response for failing tests)
I'd love to properly integrate this with dbt, but never managed to find the sweet spot in the logging system.

I agree it's not perfect, I hesitated to add it to the actual "message" because I preferred to have a dedicated log.
If we have to modify the core as well, maybe @jtcohen6 would like to be involved to be sure so that we can have some feedback regarding providing a smart interface for other adapters to provide a custom log (that would make sense to me).

@Kayrnt thank you so much for opening this PR! While testing this locally I noticed we aren't applying the set_common_attributes method as we never call it outside of itself. so we aren't currently seeing the job_id or project_id in the adapter_response ex. adapter_response={'_message': 'OK', 'code': 'CREATE VIEW'} which is causing a KeyError failure on test__bigquery_adapter_functions.

@Kayrnt thank you so much for opening this PR! While testing this locally I noticed we aren't applying the set_common_attributes method as we never call it outside of itself. so we aren't currently seeing the job_id or project_id in the adapter_response ex. adapter_response={'_message': 'OK', 'code': 'CREATE VIEW'} which is causing a KeyError failure on test__bigquery_adapter_functions.  Do you have a sense of where it is your wanting to call upon it in the execute method? @jtcohen6 any thoughts?

@McKnight-42 Thanks for the feedback, I used set_common_attributes within the execute function in all blocks. I didn't use it for CREATE_VIEW because it wasn't putting a message but I guess I could use set_common_attributes as well so I'm updating to be consistent.
I guess that if I'm doing it for all query types, then it's just clearer to inline it at the end of the specific parts.

@Kayrnt appears we may of had a slight false positive here after the changes due to a okay to test flag missing not triggering the AdapterIntegrationTests.  It looks like we are still getting the KeyError issue as seen here ci/cd tests on main. Please feel free to reopen this pr if you have time to keep working on this issue/refactor.

@McKnight-42 OK I'll have a look and try to reproduce it locally 👍


Portable vector shuffles

I've just submitted a PR with an API for portable vector shuffles (https://github.com/rust-lang-nursery/stdsimd/pull/387). From the docs:
// Shuffle allows reordering the elements of a vector:
let x = i32x4::new(1, 2, 3, 4);
let r = shuffle!(x, [2, 1, 3, 0]);
assert_eq!(r, i32x4::new(3, 2, 4, 1));

// The resulting vector can be smaller than the input:
let r = shuffle!(x, [1, 3]);
assert_eq!(r, i32x2::new(2, 4));

// Equal:
let r = shuffle!(x, [1, 3, 2, 0]);
assert_eq!(r, i32x4::new(2, 4, 3, 1));

// Or larger (at most twice as large):
et r = shuffle!(x, [1, 3, 2, 2, 1, 3, 2, 2]);
assert_eq!(r, i32x8::new(2, 4, 3, 3, 2, 4, 3, 3));

// It also allows reordering elements of two vectors:
let y = i32x4::new(5, 6, 7, 8);
let r = shuffle!(x, y, [4, 0, 5, 1]);
assert_eq!(r, i32x4::new(5, 1, 6, 2));
// And this can be used to construct larger or smaller
// vectors as well.

It would be nice to gather feed-back on this.

Does this API allow shuffling where the indices are unknown? i.e. using _mm_shuffle_epi8 where the indices vector is unknown?

The indices need to be known at compile time for the compiler to generate
the right shuffle sequence.
On Fri 22. Jun 2018 at 23:47, TheIronBorn<EMAIL_ADDRESS>wrote:

Does this API allow shuffling where the indices are unknown? i.e. using
_mm_shuffle_epi8 where the indices vector is unknown?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang-nursery/stdsimd/issues/388#issuecomment-399591547,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3NppCspl5Hj9scx5u7s7mZcI9rIjsnks5t_WXvgaJpZM4Sx823
.

This has been fixed in https://github.com/gnzlbg/packed_simd


Upgrade pulumi-terraform-bridge to v3.62.0

This PR was generated via $ upgrade-provider pulumi/pulumi-kong --kind=bridge.

Upgrading pulumi-terraform-bridge from v3.60.0 to v3.62.0.

Closing since this PR upgrade pu/pkg to a version with a known codegen bug. Trial works as expected.


Add validator for template strings (and TemplateStr type?)

Feature Request
from pydantic import BaseModel, ValidationError, TemplateStr

class Person(BaseModel):
    name: str
    greeting_template: TemplateStr['name']

    @property
    def greeting(self):
        return self.greeting_template.format(name=self.name)

person = Person(name='John', greeting_template='Hello, {name}!')
print(person.greeting)  # Hello, John!

try:
    Person(name='Emmy', greeting_template='Oops!')
except ValidationError as e:
    print(e)
'''
1 validation error for Person
greeting_template
  invalid template string, expected keys: ('name',), actual keys: () (type=value_error.str.template; expected_keys=('name',); actual_keys=())
'''

I think this kind of validator can be useful.
Also, do you think it should be a separate type like in example, or should it be implemented in constr?
Once we agree on implementation details, I can make a PR.

Is there a safe way to do the substitution?
http://lucumr.pocoo.org/2016/12/29/careful-with-str-format/

So basically, f-strings pose injection risks. That's a very interesting vulnerability! Thanks for sharing @samuelcolvin I wasn't aware of that.

Yes.
Alternative is our own templating logic (horror), or using an external library, but must of them don't allow untrusted templates.

Well, that's good catch, @samuelcolvin
We have built-in string.Formatter.parse method, which gives us information about formatted string keys:
import json
from string import Formatter

ALLOWED_KEY = 'name'

def check_str(string: str):
    for literal_text, field_name, format_spec, conversion in Formatter().parse(string):
        print(json.dumps(locals(), indent=4))
        print(field_name == ALLOWED_KEY)

check_str('Harmless hello to {name}')
check_str('Potential injection attack to {name.__class__}')
"""
{
    "conversion": null,
    "format_spec": "",
    "field_name": "name",
    "literal_text": "Harmless hello to ",
    "string": "Harmless hello to {name}"
}
True
{
    "conversion": null,
    "format_spec": "",
    "field_name": "name.__class__",
    "literal_text": "Potential injection attack to ",
    "string": "Potential injection attack to {name.__class__}"
}
False

"""

So in my implementation, this vulnerabilities will be eliminated on validation.

Okay, that's interesting, but what do we allow?
Just simple string substitution, or things like formatters, getitem, some getattr?
Also native formatting does allow "if" blocks and loops.
Surely better to leave this out of pydantic and let people do it their own way.
I don't think this requires any other changes to pydantic does it?

Surely better to leave this out of pydantic and let people do it their own way.

Agreed. So I guess a simplest way to resolve it is to check the keys as they were written in type so TemplateStr['name.__class__!r:20'] will allow strings with exactly same key: 'foo {name.__class__!r:20}' and not 'foo {name!r}' or '{name.__class.__name__}', etc.

I don't think this requires any other changes to pydantic does it?

Don't think so either

What do others think?
Feedback very welcome.
Would you ever use this feature?
See #942 for an example implementation.

I don't know when we need the feature.
Also, I have read the example, I feel it is too difficult to understand. (eg:  d: TemplateStr[3] number is a count of positional argument)
@MrMrRobat
I think you should tell us when we need the feature with real case.
I don't find the situation.

I think you should tell us when we need the feature with real case.

Well, now I'm building a service where some strings could be edited from external API and reloaded in application. So this type is very useful in this case, when you need to make sure that they have all needed keys and no additional keys in them.
Other case is when we use some environment variables, config, etc, which must contain specific key/keys.
For example:
class Messages(BaseModel):
    greeting: TemplateStr['username']
    wrong_action: TemplateStr['action']
    ...

with open('messages.json') as f:
    messages = Messages(**json.load(f))

Sorry I'm being dumb, I'm still not clear from this example what TemplateStr does.

No problem!  Does this one seems clearer?
from pydantic import BaseModel, ValidationError, TemplateStr

class Messages(BaseModel):
    greeting: TemplateStr['username']
    wrong_action: TemplateStr['action']

good_messages = {
    'greeting': 'Hello, {username}!', 'wrong_action': 'This is wrong: {action}'
}
bad_messages = (
    {'greeting': 'Hello, world!', 'wrong_action': 'Oops, that was wrong'},
    {'greeting': 'Hello, {username} and {othername}', 'wrong_action': '{action.__class__}'}
)

Messages(**good_messages)  # ok!

for bad in bad_messages:
    try:
        Messages(**bad)
    except ValidationError as e:
        print('\n', e)

'''
 2 validation errors for Messages
greeting
  invalid template string, expected keys: {'username'}, actual keys: set() (type=value_error.str.template; expected_keys={'username'}; actual_keys=set())
wrong_action
  invalid template string, expected keys: {'action'}, actual keys: set() (type=value_error.str.template; expected_keys={'action'}; actual_keys=set())

 2 validation errors for Messages
greeting
  invalid template string, expected keys: {'username'}, actual keys: {'othername', 'username'} (type=value_error.str.template; expected_keys={'username'}; actual_keys={'othername', 'username'})
wrong_action
  invalid template string, expected keys: {'action'}, actual keys: {'action.__class__'} (type=value_error.str.template; expected_keys={'action'}; actual_keys={'action.__class__'})
'''

@MrMrRobat
Thank you for your example.
The feature may use to check a custom template of an email.
However, I don't know that we should implement it with pydantic 🤔

Okay, I've thought about this and I don't think it belongs in pydantic.
It's somewhat confusing and not a core part of what pydantic does, it's also easy enough to implement out side pydantic.
Sorry, hope that's okay.


TopNav changes

changes requested in move to prod pull request have been made. code in container.js has been moved to TopNav.jsx, method added to make icon requires dry.

Looks good to me. Good use of that function. I like that.


Add Error.Trace*(), and make Wrap/WithMessage never nest.

"The traditional error handling idiom in Go is roughly akin to .... which applied recursively up the call stack results in error reports without context or debugging information. The errors package allows programmers to add context to the failure path in their code in a way that does not destroy the original value of the error."

Even if you generate a stack trace at the source, callers of a function (which returns an error) will in general want to wrap it again to add more context, and the preferred method is to use errors.Wrap(), not errors.WithMessage().
, err := externalFunction(r)
if err != nil {
        return errors.Wrap(err, "msg") // or should we .WithMessage??
}

Perhaps there could be a more intelligent automatic way to choose between errors.Wrap() or errors.WithMessage(), but what would that look like?  The only obvious 100%-correct-general-solution given the state of github.com/pkg/errors today (without assuming anything about the implementation of externalFunction() error) is to always use errors.WithMessage() but include minimal trace information like the filename and line number.
So OK, if github.com/pkg/errors starts advertising errors.WithMessage() as the primary method of adding contextual information, and its implementation is changed to include a modicum of trace information (filename, lineno), (or if errors.Wrap() were changed to include only minimal trace information), then we're 89% of the way there.  But there's still a problem.
In general, it breaks the intent of Golang to wrap an error with github.com/pkg/errors.Error, because it breaks the one way that we're supposed to deal with error control flow... that is, we're supposed to switch on err behavior (or err concrete type, though it's not preferred).
type FooError struct{}
func (_ FooError) Error() string { return "" }

type BarError error

func externalFunc() error { return nil }

func main() {
	err := externalFunc()
	switch err.(type) {
	case FooError:
		// handle FooError
	case BarError:
		// handle BarError
	}
	fmt.Println("Hello, playground")
}

And github.com/pkg/errors violates that.  There exists errors.Cause(), but now you have to dig down to the first non-errors.Error-error before you can type-check like above.  And you can't just take the root-most cause of an error unless you preclude other custom error types from having a cause.
The solution is to not wrap an error, but to add trace information to the same error object. Ultimately it is error itself that needs to be a tracer.
If github.com/pkg/errors were to always keep a single (non-nested) Error by returning the same github.com/pkg/errors.Error upon errors.Wrap() and errors.WithMessage(), then we can switch confidently on behavior:
var err error := externalFunc()
switch err := errors.Unwrap(err).(type) {
case FooError:
	// handle FooError
case BarError:
	// handle BarError
}

The name for errors.Unwrap() is tricky... It can't be errors.Cause() because if it were a non-github.com/pkg/errors.Error causer error, we'd be switching on the wrong error.  So Unwrap seems like a better name.
The problem is that it isn't 100% consistent with errors.Wrap(), because you only need to unwrap once what was wrapped a million times.  Maybe errors.Wrap() should be deprecated, and errors.TraceWithError(error) error could ensure that the error err is already a errors.Error (in which case it would pass it through after calling err.Trace()) or else it would return errors.Wrap(err).  Maybe errors.Unwrap() should be called errors.MaybeUnwrap().
Original discussion: https://github.com/golang/go/issues/23271#issuecomment-354531105

If github.com/pkg/errors were to always keep a single (non-nested) Error by returning the same github.com/pkg/errors.Error upon .Wrap() and .WithMessage(), then its .Cause() can work like so:
	err := externalFunc()
	switch err := errors.ImmediateCause(err).(type) {
	case FooError:
		// handle FooError
	case BarError:
		// handle BarError
	}

“the preferred method is to use errors.Wrap(), not errors.WithMessage().” False. Is it by far the most common? Yes. But it is not the “preferred method”. errors.Wrap should only be used when one wishes to attach not only a message, but a stack trace. If one wants to just add a message, then errors.WithMessage is the proper function to call.
“Perhaps there could be a more intelligent automatic way to choose between errors.Wrap() or errors.WithMessage(), but what would that look like?” It’s called a programmer, and it is a human being capable of intelligent decision making.
“that is, we're supposed to switch on err behavior (or err concrete type, though it's not preferred)“ False, we want to test for implementation of interfaces:
_, err := FunctionReturningMaybeError()
if err != nil {
   err := errors.Cause(err)
   if _, ok := err.(interface{ Retryable() bool }); ok {
     // doRetryBehavior here
   }
}

https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

“the preferred method is to use errors.Wrap(), not errors.WithMessage().” False. Is it by far the most common? Yes. But it is not the “preferred method”. errors.Wrap should only be used when one wishes to attach not only a message, but a stack trace. If one wants to just add a message, then errors.WithMessage is the proper function to call.

Yes, that's obvious.  You're completely missing the point.  Earlier, you wrote in another thread that:

A stacktrace at the generation of the error itself should be sufficient to isolate where the error was generated, and that is precisely what github.com/pkg/errors.New and github.com/pkg/errors.Errorf do.

This is only partially true, or in other words, wrong.
If you're saying that the original cause of the error happened to use github.com/pkg/errors.[New/Errorf] and captured a stack-trace, then that is sufficient, then I completely agree with you. Indeed, all we need is a stack-trace at the very origin of the error (aka the "underlying" cause or "root" cause).  It would be wasteful to capture anything more!
But midway in the stack, a caller doesn't know whether the "underlying" cause happened to capture the stack with github.com/pkg/errors.[New/Errorf], or whether any .Wrap() had been called either.  There's no way for a function in the middle of the stack to know whether any stack-trace had already happened.  So the only safe thing to do is to call .Wrap(), but that captures pretty much the whole stack-trace (actually just 32 according to the implementation of capture(), which is a compromise between capturing the whole stack-trace and not capturing enough -- the worst of both worlds).

“Perhaps there could be a more intelligent automatic way to choose between errors.Wrap() or errors.WithMessage(), but what would that look like?” It’s called a programmer, and it is a human being capable of intelligent decision making.

Ok, so say you are given func ExternalFunc() error, and you wanted to add some context to this error.  Do you call .Wrap() or .WithMessage(), if you knew that the function you are implementing is in a performance critical path?  Show me how it's done, intelligent programmer!

“that is, we're supposed to switch on err behavior (or err concrete type, though it's not preferred)“ False, we want to test for implementation of interfaces:

That's what switching on "behavior" means.  Did you know that you could switch on interfaces?  Now you do.

@puellanivis I just found 4 existing issues actually related to the problem that this proposal fixes.

So the only safe thing to do is to call .Wrap()

False. If you are calling a package and you need to know the stacktrace at your point for debugging, you call Wrap, if not, you do not, then you don’t need to use Wrap. What good will it do you to trace an errors.New stack to someone else’s package? Unless you intend to debug someone else’s package.

Try to answer this question, please.

Check the dependencies of the package you’re calling. If it calls into pkg/errors finished. WithMessage. Otherwise, use WithMessage.

(Did you know that you could switch on interfaces?)

No, I patched a subtle shadowing bug in the RPC code at Google, and didn’t learn that I could use an Interface in a type assertion.

I just found 4 existing issues actually related to the problem that this proposal fixes.

And two of them are closed, and others are unimplementable.

False. If you are calling a package and you need to know the stacktrace at your point for debugging, you call Wrap, if not, you do not, then you don’t need to use Wrap.

You've conveniently ignored my point about O(N) stack traces.

What good will it do you to trace an errors.New stack to someone else’s package? Unless you intend to debug someone else’s package.

If there were traces left in by someone else's package, they were left there because it would actually be useful for debugging.  If we followed the tracer convention of calling .Trace() only when it would be useful, what's the point of capturing the whole stack-trace?
var err = externalFunction()
switch err.(type) { ... }
return

What's the point of allowing externalFunction to capture the stack-trace including the ancestral callers, when the error is going to be handled completely without that info?

No, I patched a subtle shadowing bug in the RPC code at Google, and didn’t learn that I could use an Interface in a type assertion.

can't tell if you're being sarcastic... #dontcare

can't tell if you're being sarcastic...

Yes, I am being sarcastic, because apparently you think I don’t know that a type switch can use interfaces.

Dontcare, and false.

No, that is not false. The two that are open are unimplementable, and I have commented about how they are so.
I understand, you’re attached to this idea, but it is not a good proposal. Especially as a universal change to the language itself.
I‘ve worked on this issue for over 2 years now, trying to come up with the ideal solution, the solution as currently available is the best available, and changing the language to “fix it” is not always the right solution.

Yes, I am being sarcastic, because apparently you think I don’t know that a type switch can use interfaces.

I showed you a type-switch on an interface, even pointed out that type-switching on the concrete type is possible but not preferred, and you said that I was wrong, and showed a non-type-switch version of the same concept.  It's a natural conclusion to draw.

The two that are open are unimplementable, and I have commented about how they are so.

I've shown you the solution, it's under section "Partial solution".  You'll have to find a flaw in that solution.

@jaekwon @puellanivis time for a time out please. Please revisit this discussion in the new year once you’ve calmed down.
Thank you

Thanks for moderating, Dave.  Sorry for getting the convo heated, Cassondra.
I agree that full stacktraces are also nice, in addition to tracing.  I've taken all the concepts here and implemented them here:  https://github.com/tendermint/tmlibs/blob/develop/common/errors.go
For your reference, here's a concrete case of extending tmlibs/common.Error: https://github.com/cosmos/cosmos-sdk/issues/766
Any feedback appreciated!

I just stepped onto it as well: the "idiomatic" use of this package makes the original stack trace unavailable.
The origin of the problem still is easy to guess from the error message (thanks to the wrapping), but it overwriting the stack renders the whole idea of having the stack at all useless.

How does using this package make the original stack trace unavailable. The goal of this package is to preserve the original error.

@davecheney if you errors.Wrap multiple times - then the original stack would be unavailable.
package main

import (
	"github.com/pkg/errors"
)

func foo() error {
	return errors.New("foo")
}

func bar() error {
	return errors.Wrap(foo(), "bar")
}

func baz() error {
	return errors.Wrap(bar(), "bar")
}

func main() {
	err := baz()

	// extract stack here
}


SISDR loss

Hi, Thanks for sharing this useful repo.
I want to use SISDR as loss function during training.
here is an example of target and input:
inputs = torch.rand(8,1,44100)
target = torch.rand(8,1,44100)
loss=SISDRLoss(inputs,target)
print(loss)
But it only returns  :
SISDRLoss()
and I can't calculate SI SDR loss value with this.
Please help me...
Thanks

Hi, thanks for checking out auraloss.
I think the issue is that you must first instantiate the SISDRLoss module first.
For example:
inputs = torch.rand(8,1,44100)
target = torch.rand(8,1,44100)
sisdr_loss = SISDRLoss() # instantiate the loss module
loss = sisdr_loss(inputs,target) # measure the loss
print(loss)

Let me know if this addresses your issue.

Yes, it works.
Thanks

Is there any way to use SI-SDR loss with PIT (permutation invariant of sources during training source separation model)?

Sorry for the delay on responding to this. Currently we don't have support for PIT and likely won't add it. You could try using auraloss loss function with the PIT wrapper from
Asteroid (https://github.com/asteroid-team/pytorch-pit/blob/master/torch_pit/pit_wrapper.py).


Exclusion Report | Fuel Type |1|

Info:
This card is to create the Fuel Type column, which enables the user to indicate the type of fuel that was purchased/sold under an exclusion agreement.
Design:
Drop-down menu with options informed from the "Fuel Types" Credit Calculations table. This uses the same functionality for selecting fuel types as that within the different schedules of the compliance report.

Does not include petroleum-based gasoline and diesel (it uses the same list as the fuel code features)

https://trello.com/c/gyoynfCg/1557-exclusion-report-fuel-type-1

 Exclusion Report | Fuel Type |1|

Done in sprint supermassive


fix: blackboard 500 error from manage external resources

Checklist

[x] the contributor license agreement is signed
[x] commit message follows commit guidelines
[ ] tests are included
[x] screenshots are included showing significant UI changes
[ ] documentation is changed or added

Description of change
Change func findAllUsages to throw UnsupportedOperationException.
Add catch statement to set error message.

Curious, both GHA new UI functional_testing jobs failed on io.github.openequella.search.AdvancedSearchPageTest but was fine on CodeBuild.
Have attempted to re-run them. Let's see what happens.

BTW... What happens in something like Canvas (which does not support Find Uses)? We should be doing the same.

Excellent, the two GHA fails are different to before, just flaky known ones.

Thanks Ian,

BTW... What happens in something like Canvas (which does not support Find Uses)? We should be doing the same.

The interesting thing is CanvasConnecterService actually implemented the func findAllUsages.

BTW... What happens in something like Canvas (which does not support Find Uses)? We should be doing the same.

The interesting thing is CanvasConnecterService actually implemented the func findAllUsages.

Gah, that's curious. Our feature matrix says otherwise... But you've drawn my attention to something else:

In CanvasConnecterService although findAllUsages is implemented and based on code history has been since before open sourcing (be worth making sure it works), findUsages is not and returns an empty array.
You'll note just above where you've made your fix is the findUsages for Bb, and it also is simply returning a null. Is that another NPE waiting to happen?
So, what is the use cases for these two functions? I think you may need to have a look and then you may need to address that second function too.

I think the findUsages is used when from the Item Summary page you click the 'Find Uses' link on the right hand of the screen (under Details heading).

We could also follow up with @cathfitz on her return.

BTW... What happens in something like Canvas (which does not support Find Uses)? We should be doing the same.

The interesting thing is CanvasConnecterService actually implemented the func findAllUsages.

Gah, that's curious. Our feature matrix says otherwise... But you've drawn my attention to something else:

In CanvasConnecterService although findAllUsages is implemented and based on code history has been since before open sourcing (be worth making sure it works), findUsages is not and returns an empty array.

You'll note just above where you've made your fix is the findUsages for Bb, and it also is simply returning a null. Is that another NPE waiting to happen?

So, what is the use cases for these two functions? I think you may need to have a look and then you may need to address that second function too.

I think the findUsages is used when from the Item Summary page you click the 'Find Uses' link on the right hand of the screen (under Details heading).

We could also follow up with @cathfitz on her return.

Thanks for your info:
findAllUsage is used when you click the left menu manage external resources and choose a connector:

findUsage is used when you click the 'Find Uses' link in the Item Summary page:

and the workflow is in FindUsesContentSection: loadUsage -> checkErrors -> getUsages -> BlackboardRESTConnectorServiceImpl:findUsage.
The server just saves it into the model and has no other process on it.

I think null is ok for this use case :


logging: use common-gax

Blockers

[ ] Introduce @google-cloud/common-gax (#2234)

This converts the Logging API to use common-gax.

We're going a different way (#2272).


Error locator degree does not match number of roots

I get this error code Error locator degree does not match number of roots Everytime I try to add to process QR code on my node server script however when I scan those QR codes on phone they return me expected results

Hi i keep getting the same, but when i run the same image through zbar it can read it.
i removed the qr reader and now execute zbarimg
https://centos.pkgs.org/6/epel-x86_64/zbar-0.10-25.el6.x86_64.rpm.html
var exec = require('child_process').exec;

var newn = "/var/qr/file_422.jpg"
var Vcommand = "zbarimg "+newn;
exec(Vcommand, function(error, stdout, stderr){
         console.log(stdout);
}

Same error here, if you found a workaround it'll help me a lot @qvs5010

@qvs5010 i have the same issue if you have found a solution (with the npm package) it would be great, i'll keep searching.
Thank you

Any update on the issue? :)

Hello, guys ! does anyone has a solution ?

I can only suggest moving to https://github.com/cozmo/jsQR.
If required read an image using tool like jimp (https://www.npmjs.com/package/jimp) so you have an Uint8ClampedArray of RGBA pixel values.
It just handles all QR codes I previously had problems with perfectly.


op-reth: block import issue

Describe the bug
unable to import bedrock block data when using optimism on v1.0.2 following the latest guide
op-reth import-op --datadir=/datas /artifacts/artifacts/blocks.rlp --chain=optimism
2024-07-18T18:51:34.947212Z  INFO Initialized tracing, debug log directory: /root/.cache/reth/logs/optimism
2024-07-18T18:51:34.953160Z  INFO reth 1.0.2-dev (ffb44e62) starting
2024-07-18T18:51:34.953201Z  INFO Disabled stages requiring state, since cannot execute OVM state changes
2024-07-18T18:51:34.957055Z  INFO Opening storage db_path="/datas/db" sf_path="/datas/static_files"
2024-07-18T18:51:34.969051Z  INFO Verifying storage consistency.
2024-07-18T18:51:42.841473Z  INFO Importing chain file chunk
2024-07-18T18:51:42.854687Z  INFO Chain file chunk read
2024-07-18T18:51:43.232837Z  INFO Downloading bodies count=1166778 range=0..=1166777
thread 'tokio-runtime-worker' panicked at /app/crates/stages/api/src/pipeline/set.rs:206:18:
Cannot disable a stage that is not in the set.
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at /app/crates/cli/runner/src/lib.rs:102:63:
Failed to join task: JoinError::Panic(Id(17), ...)
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Steps to reproduce
Following the Guide from https://reth.rs/run/sync-op-mainnet.html
I first downloaded the bedrock data using the link in the docs
I downloaded and ran https://github.com/testinprod-io/op-geth/blob/pcw109550/bedrock-db-migration/migrate.sh with the following arguments 105235063 /data /data/artifacts to export the bedrock data
the following command fails on 1.0.2 but passes with 1.0.1 and 1.0.0
reth import-op --datadir=/datas /data/artifacts/blocks.rlp --chain=optimism
Node logs
2024-07-18T18:45:00.755240Z  INFO reth::cli: Initialized tracing, debug log directory: /root/.cache/reth/logs/optimism
2024-07-18T18:45:00.755522Z TRACE mio::poll: registering event source with poller: token=Token(1), interests=READABLE
2024-07-18T18:45:00.761086Z  INFO reth::cli: reth 1.0.2-dev (ffb44e62) starting
2024-07-18T18:45:00.761125Z  INFO reth::cli: Disabled stages requiring state, since cannot execute OVM state changes
2024-07-18T18:45:00.761132Z DEBUG reth::cli: Chunking chain import chunk_byte_len=1000000000
2024-07-18T18:45:00.767185Z  INFO reth::cli: Opening storage db_path="/datas/db" sf_path="/datas/static_files"
2024-07-18T18:45:00.779897Z DEBUG storage::db::mdbx: Commit total_duration=2.293409ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 1, audit: 0, write: 0, sync: 146, ending: 0, whole: 147, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-07-18T18:45:00.783238Z  INFO reth::cli: Verifying storage consistency.
2024-07-18T18:45:00.783330Z TRACE providers::static_file: Getting static file writer. block=0 segment=Headers
2024-07-18T18:45:00.791956Z TRACE providers::static_file: Getting static file writer. block=0 segment=Transactions
2024-07-18T18:45:00.801237Z TRACE providers::static_file: Getting static file writer. block=0 segment=Receipts
2024-07-18T18:45:00.808654Z DEBUG reth::cli: Initializing genesis chain=optimism genesis=0x7ca38a1916c42007829c55e69d3e9a73265554b586a499015373241b8a3fa48b
2024-07-18T18:45:00.808692Z DEBUG reth_db_common::init: Writing genesis block.
2024-07-18T18:45:00.809517Z TRACE reth::cli: Inserted account hashes
2024-07-18T18:45:00.810583Z TRACE reth::cli: Inserted storage hashes
2024-07-18T18:45:00.810598Z TRACE reth::cli: Inserted account history
2024-07-18T18:45:00.810608Z TRACE reth::cli: Inserted storage history
2024-07-18T18:45:00.810625Z TRACE providers::static_file: Getting static file writer. block=0 segment=Headers
2024-07-18T18:45:00.812168Z TRACE provider::reverts: Writing storage changes
2024-07-18T18:45:00.812185Z TRACE provider::reverts: Writing block change block_number=0
2024-07-18T18:45:00.813491Z TRACE provider::reverts: Writing account changes
2024-07-18T18:45:00.813507Z TRACE provider::bundle_state: Writing new account state len=0
2024-07-18T18:45:00.813512Z TRACE provider::bundle_state: Writing bytecodes len=0
2024-07-18T18:45:00.813517Z TRACE provider::bundle_state: Writing new storage state len=0
2024-07-18T18:45:00.813521Z TRACE reth::cli: Inserted state
2024-07-18T18:45:00.815610Z DEBUG storage::db::mdbx: Commit total_duration=2.061829ms commit_latency=Some(CommitLatency(MDBX_commit_latency { preparation: 0, gc_wallclock: 1, audit: 0, write: 0, sync: 129, ending: 0, whole: 131, gc_cputime: 0, gc_prof: MDBX_commit_latency__bindgen_ty_1 { wloops: 0, coalescences: 0, wipes: 0, flushes: 0, kicks: 0, work_counter: 0, work_rtime_monotonic: 0, work_xtime_cpu: 0, work_rsteps: 0, work_xpages: 0, work_majflt: 0, self_counter: 0, self_rtime_monotonic: 0, self_xtime_cpu: 0, self_rsteps: 0, self_xpages: 0, self_majflt: 0 } })) is_read_only=false
2024-07-18T18:45:00.821113Z DEBUG provider::static_file: Commit segment=Headers path="/datas/static_files/static_file_headers_0_499999" duration=5.473039ms
2024-07-18T18:45:02.527239Z DEBUG downloaders::file: new bytes were read from file max_chunk_byte_len=1000000000 prev_read_bytes_len=0 new_read_bytes_target_len=1000000000 new_read_bytes_len=1000000000 next_chunk_byte_len=1000000000 remaining_file_byte_len=108803069972
2024-07-18T18:45:02.527819Z TRACE downloaders::file: init decode stream target_num_bytes=1000000000 capacity=1000000000
2024-07-18T18:45:02.726095Z TRACE downloaders::file: read first block block_number=0
2024-07-18T18:45:03.231983Z TRACE downloaders::file: read blocks from file blocks=0..=100000
2024-07-18T18:45:03.739708Z TRACE downloaders::file: read blocks from file blocks=100001..=200000
2024-07-18T18:45:04.299791Z TRACE downloaders::file: read blocks from file blocks=200001..=300000
2024-07-18T18:45:04.774242Z TRACE downloaders::file: read blocks from file blocks=300001..=400000
2024-07-18T18:45:05.664186Z TRACE downloaders::file: read blocks from file blocks=400001..=500000
2024-07-18T18:45:06.131371Z TRACE downloaders::file: read blocks from file blocks=500001..=600000
2024-07-18T18:45:06.652460Z TRACE downloaders::file: read blocks from file blocks=600001..=700000
2024-07-18T18:45:07.186965Z TRACE downloaders::file: read blocks from file blocks=700001..=800000
2024-07-18T18:45:07.715586Z TRACE downloaders::file: read blocks from file blocks=800001..=900000
2024-07-18T18:45:09.277382Z TRACE downloaders::file: read blocks from file blocks=900001..=1000000
2024-07-18T18:45:09.838240Z TRACE downloaders::file: read blocks from file blocks=1000001..=1100000
2024-07-18T18:45:10.213831Z TRACE downloaders::file: partial block returned from decoding chunk err=input too short bytes_len=752
2024-07-18T18:45:10.214544Z TRACE downloaders::file: Initialized file client blocks=1166778
2024-07-18T18:45:10.229614Z  INFO reth::cli: Importing chain file chunk
2024-07-18T18:45:10.245757Z  INFO reth::cli: Chain file chunk read
2024-07-18T18:45:10.562200Z TRACE downloaders::headers: The downloader sync boundaries have not been set head=Some(0) sync_target=None
2024-07-18T18:45:10.572842Z TRACE downloaders::headers: Update sync target current=None new=0x96a50ed06c38c9bd71012d47da45968a3adbed4a4e0560d4ea29c651e00d765a
2024-07-18T18:45:10.573968Z TRACE downloaders::headers: Request new sync target new=Tip(0x96a50ed06c38c9bd71012d47da45968a3adbed4a4e0560d4ea29c651e00d765a)
2024-07-18T18:45:10.573983Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Hash(0x96a50ed06c38c9bd71012d47da45968a3adbed4a4e0560d4ea29c651e00d765a), limit: 1, direction: Falling }
2024-07-18T18:45:10.573994Z TRACE downloaders::file: Getting headers with range range=Left(1166777..1166778)
2024-07-18T18:45:10.574051Z TRACE downloaders::headers: Received sync target head=Some(0) hash=0x96a50ed06c38c9bd71012d47da45968a3adbed4a4e0560d4ea29c651e00d765a number=1166777
2024-07-18T18:45:10.575165Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1166776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.575191Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1166776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.575198Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1166776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.575205Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1165777..=1166776 })
2024-07-18T18:45:10.575864Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1165776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.575881Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1165776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.575888Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1165776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.575901Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1164777..=1165776 })
2024-07-18T18:45:10.576500Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1164776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.576516Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1164776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.576522Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1164776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.576552Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1163777..=1164776 })
2024-07-18T18:45:10.577684Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1163776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.577697Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1163776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.577701Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1163776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.577705Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1162777..=1163776 })
2024-07-18T18:45:10.578302Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1162776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.578318Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1162776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.578322Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1162776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.578326Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1161777..=1162776 })
2024-07-18T18:45:10.578899Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.579809Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1166776 highest=1166776
2024-07-18T18:45:10.595584Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.595621Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1165776 highest=1165776
2024-07-18T18:45:10.597506Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.597535Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1164776 highest=1164776
2024-07-18T18:45:10.599227Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.599267Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1163776 highest=1163776
2024-07-18T18:45:10.600450Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.600503Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1162776 highest=1162776
2024-07-18T18:45:10.602806Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1161776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.602831Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1161776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.602853Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1161776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.602865Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1160777..=1161776 })
2024-07-18T18:45:10.603495Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1160776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.603511Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1160776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.603516Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1160776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.603520Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1159777..=1160776 })
2024-07-18T18:45:10.604168Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1159776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.604184Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1159776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.604188Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1159776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.604192Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1158777..=1159776 })
2024-07-18T18:45:10.604896Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1158776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.604909Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1158776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.604913Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1158776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.604918Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1157777..=1158776 })
2024-07-18T18:45:10.605028Z TRACE downloaders::bodies: Download range reset range=0..=1166777 prev_range=1..=0
2024-07-18T18:45:10.605108Z  INFO downloaders::bodies: Downloading bodies count=1166778 range=0..=1166777
2024-07-18T18:45:10.605568Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1157776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.605581Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1157776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.605585Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1157776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.605590Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1156777..=1157776 })
2024-07-18T18:45:10.606214Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.606235Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1161776 highest=1161776
2024-07-18T18:45:10.607396Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.607420Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1160776 highest=1160776
2024-07-18T18:45:10.608682Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.608714Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1159776 highest=1159776
2024-07-18T18:45:10.609784Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.609811Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1158776 highest=1158776
2024-07-18T18:45:10.612249Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.612279Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1157776 highest=1157776
2024-07-18T18:45:10.613048Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1156776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.613066Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1156776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.613072Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1156776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.613082Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1155777..=1156776 })
2024-07-18T18:45:10.613700Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1155776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.613711Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1155776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.613715Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1155776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.613719Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1154777..=1155776 })
2024-07-18T18:45:10.614377Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1154776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.614388Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1154776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.614392Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1154776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.614395Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1153777..=1154776 })
2024-07-18T18:45:10.615009Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1153776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.615019Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1153776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.615023Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1153776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.615027Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1152777..=1153776 })
2024-07-18T18:45:10.615694Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1152776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.615701Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1152776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.615705Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1152776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.615709Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1151777..=1152776 })
2024-07-18T18:45:10.617161Z TRACE downloaders::headers: Returning validated batch batch=10000
2024-07-18T18:45:10.617194Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.617206Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1156776 highest=1156776
2024-07-18T18:45:10.618567Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.618605Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1155776 highest=1155776
2024-07-18T18:45:10.619919Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.619952Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1154776 highest=1154776
2024-07-18T18:45:10.621049Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.621078Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1153776 highest=1153776
2024-07-18T18:45:10.622274Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.622308Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1152776 highest=1152776
2024-07-18T18:45:10.623475Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1151776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.623493Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1151776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.623500Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1151776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.623505Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1150777..=1151776 })
2024-07-18T18:45:10.624165Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1150776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.624184Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1150776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.624188Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1150776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.624192Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1149777..=1150776 })
2024-07-18T18:45:10.624893Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1149776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.624908Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1149776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.624913Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1149776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.624917Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1148777..=1149776 })
2024-07-18T18:45:10.625599Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1148776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.625612Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1148776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.625616Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1148776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.625620Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1147777..=1148776 })
2024-07-18T18:45:10.626338Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1147776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.626353Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1147776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.626357Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1147776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.626360Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1146777..=1147776 })
2024-07-18T18:45:10.626981Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.627001Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1151776 highest=1151776
2024-07-18T18:45:10.628078Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.628103Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1150776 highest=1150776
2024-07-18T18:45:10.629236Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.629260Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1149776 highest=1149776
thread 'tokio-runtime-worker' panicked at /app/crates/stages/api/src/pipeline/set.rs:206:18:
Cannot disable a stage that is not in the set.
stack backtrace:
2024-07-18T18:45:10.630094Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.630120Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1148776 highest=1148776
2024-07-18T18:45:10.632086Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.632107Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1147776 highest=1147776
2024-07-18T18:45:10.632894Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1146776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.632912Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1146776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.632918Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1146776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.632923Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1145777..=1146776 })
2024-07-18T18:45:10.633547Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1145776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.633559Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1145776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.633564Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1145776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.633568Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1144777..=1145776 })
2024-07-18T18:45:10.634202Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1144776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.634214Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1144776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.634218Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1144776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.634222Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1143777..=1144776 })
2024-07-18T18:45:10.634795Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1143776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.634807Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1143776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.634811Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1143776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.634815Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1142777..=1143776 })
2024-07-18T18:45:10.635376Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1142776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.635387Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1142776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.635391Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1142776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.635395Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1141777..=1142776 })
2024-07-18T18:45:10.635976Z TRACE downloaders::headers: Returning validated batch batch=10000
2024-07-18T18:45:10.635992Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.636000Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1146776 highest=1146776
2024-07-18T18:45:10.637118Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.637136Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1145776 highest=1145776
2024-07-18T18:45:10.637912Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.637931Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1144776 highest=1144776
2024-07-18T18:45:10.638754Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.638770Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1143776 highest=1143776
2024-07-18T18:45:10.639330Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.639346Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1142776 highest=1142776
2024-07-18T18:45:10.640356Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1141776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.640368Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1141776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.640373Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1141776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.640377Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1140777..=1141776 })
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2024-07-18T18:45:10.640932Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1140776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.640946Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1140776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.640951Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1140776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.640956Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1139777..=1140776 })
2024-07-18T18:45:10.641525Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1139776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.641537Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1139776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.641540Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1139776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.641543Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1138777..=1139776 })
2024-07-18T18:45:10.642126Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1138776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.642137Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1138776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.642141Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1138776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.642144Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1137777..=1138776 })
2024-07-18T18:45:10.642687Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1137776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.642697Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1137776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.642700Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1137776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.642704Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1136777..=1137776 })
2024-07-18T18:45:10.643208Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.643221Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1141776 highest=1141776
2024-07-18T18:45:10.643915Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.643932Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1140776 highest=1140776
2024-07-18T18:45:10.644634Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.644659Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1139776 highest=1139776
thread 'main' panicked at /app/crates/cli/runner/src/lib.rs:102:63:
Failed to join task: JoinError::Panic(Id(17), ...)
stack backtrace:
2024-07-18T18:45:10.645415Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.645437Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1138776 highest=1138776
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2024-07-18T18:45:10.648114Z TRACE downloaders::headers: Received headers response len=1000
2024-07-18T18:45:10.648148Z TRACE downloaders::headers: Validating non-empty headers response requested_block_number=1137776 highest=1137776
2024-07-18T18:45:10.649004Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1136776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.649018Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1136776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.649027Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1136776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.649033Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1135777..=1136776 })
2024-07-18T18:45:10.649604Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1135776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.649615Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1135776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.649619Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1135776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.649623Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1134777..=1135776 })
2024-07-18T18:45:10.650241Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1134776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.650253Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1134776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.650257Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1134776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.650260Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1133777..=1134776 })
2024-07-18T18:45:10.650838Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1133776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.650849Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1133776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.650852Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1133776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.650856Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1132777..=1133776 })
2024-07-18T18:45:10.651477Z TRACE downloaders::headers: Requesting headers HeadersRequest { start: Number(1132776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.651493Z TRACE downloaders::headers: Submitting headers request request=HeadersRequest { start: Number(1132776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.651497Z TRACE downloaders::file: Getting headers request=HeadersRequest { start: Number(1132776), limit: 1000, direction: Falling }
2024-07-18T18:45:10.651500Z TRACE downloaders::file: Getting headers with range range=Right(Rev { iter: 1131777..=1132776 })
2024-07-18T18:45:10.652212Z TRACE downloaders::headers: Returning validated batch batch=10000

Platform(s)
Linux (x86)
What version/commit are you on?
v1.0.2
What database version are you on?
2
Which chain / network are you on?
optimism
What type of node are you running?
Archive (default)
What prune config do you use, if any?
No response
If you've built Reth from source, provide the full command you used
cargo build --profile max-perf --features jemalloc,asm-keccak,optimism --locked --bin op-reth
Code of Conduct

[X] I agree to follow the Code of Conduct

closing as fixed by #9630


Close button - font increase

X button should be in the gray part - in front of the topic heading
Close button (orange one):  should have bigger font and size (like blue bubbles)

@niharikaavasthi Ready to test

@prahasithkondra @navpreetkaur051 This is not changed on CanBeWell1.0?

@niharikaavasthi : DOne in can be well 1 as well.

checked_on_iPhone-TESTED

checked_on_Windows-TESTED

The size of the orange "Close" looks smaller

than the blue bubbles.

@niharikaavasthi checked_on_Ipad-TESTED. It is good.

checked_on_Android-TESTED

Checked on windows (EN - Patients) for production. Looks good.

Checked on iPhone (EN) Functionality good

Tested successfully on CanBeWell1.0


Decompression Layer Testing fails on Pixel 7

Seeing the following tests fail on a pixel 7 device:
[==========] Running 17 tests from 3 test suites.
[----------] Global test environment set-up.
[----------] 14 tests from Sync2Test
[ RUN      ] Sync2Test.OwnershipTranfersImage
/home/john/work/repos/Vulkan-ExtensionLayer/tests/synchronization2_tests.cpp:120: Skipped
             TEST SKIPPED:Required queue families not present (non-graphics capable required).

[  SKIPPED ] Sync2Test.OwnershipTranfersImage (20 ms)
[ RUN      ] Sync2Test.OwnershipTranfersBuffer
/home/john/work/repos/Vulkan-ExtensionLayer/tests/synchronization2_tests.cpp:174: Skipped
             TEST SKIPPED:Required queue families not present (non-graphics capable required).

[  SKIPPED ] Sync2Test.OwnershipTranfersBuffer (17 ms)
[ RUN      ] Sync2Test.SecondaryCommandBufferBarrier
[       OK ] Sync2Test.SecondaryCommandBufferBarrier (17 ms)
[ RUN      ] Sync2Test.SecondaryCommandBufferImageLayoutTransitions
[       OK ] Sync2Test.SecondaryCommandBufferImageLayoutTransitions (18 ms)
[ RUN      ] Sync2Test.QueueSubmitSemaphoresAndLayoutTracking
[       OK ] Sync2Test.QueueSubmitSemaphoresAndLayoutTracking (17 ms)
[ RUN      ] Sync2Test.CommandBufferSimultaneousUseSync
[       OK ] Sync2Test.CommandBufferSimultaneousUseSync (14 ms)
[ RUN      ] Sync2Test.BarrierLayoutToImageUsage
[       OK ] Sync2Test.BarrierLayoutToImageUsage (20 ms)
[ RUN      ] Sync2Test.WaitEventThenSet
[       OK ] Sync2Test.WaitEventThenSet (16 ms)
[ RUN      ] Sync2Test.TwoQueueSubmitsSeparateQueuesWithSemaphoreAndOneFenceTwoWFF
[       OK ] Sync2Test.TwoQueueSubmitsSeparateQueuesWithSemaphoreAndOneFenceTwoWFF (14 ms)
[ RUN      ] Sync2Test.TwoSubmitInfosWithSemaphoreOneQueueSubmitsOneFence
[       OK ] Sync2Test.TwoSubmitInfosWithSemaphoreOneQueueSubmitsOneFence (15 ms)
[ RUN      ] Sync2Test.ClearDepthStencilWithValidRange
[       OK ] Sync2Test.ClearDepthStencilWithValidRange (17 ms)
[ RUN      ] Sync2Test.QueueSubmitTimelineSemaphore
[       OK ] Sync2Test.QueueSubmitTimelineSemaphore (15 ms)
[ RUN      ] Sync2Test.SwapchainImage
[       OK ] Sync2Test.SwapchainImage (31 ms)
[ RUN      ] Sync2Test.EnumerateDeviceExtensionProperties
[       OK ] Sync2Test.EnumerateDeviceExtensionProperties (15 ms)
[----------] 14 tests from Sync2Test (254 ms total)

[----------] 1 test from Sync2CompatTest
[ RUN      ] Sync2CompatTest.Vulkan10
[       OK ] Sync2CompatTest.Vulkan10 (9 ms)
[----------] 1 test from Sync2CompatTest (9 ms total)

[----------] 2 tests from DecompressionTest
[ RUN      ] DecompressionTest.DecompressMemory
/home/john/work/repos/Vulkan-ExtensionLayer/tests/decompression_tests.cpp:121: Failure
Value of: compareResult == 0
  Actual: false
Expected: true

[  FAILED  ] DecompressionTest.DecompressMemory (607 ms)
[ RUN      ] DecompressionTest.DecompressMemoryIndirect
/home/john/work/repos/Vulkan-ExtensionLayer/tests/decompression_tests.cpp:221: Failure
Value of: compareResult == 0
  Actual: false
Expected: true

[  FAILED  ] DecompressionTest.DecompressMemoryIndirect (574 ms)
[----------] 2 tests from DecompressionTest (1182 ms total)

[----------] Global test environment tear-down
[==========] 17 tests from 3 test suites ran. (1448 ms total)
[  PASSED  ] 13 tests.
[  SKIPPED ] 2 tests, listed below:
[  SKIPPED ] Sync2Test.OwnershipTranfersImage
[  SKIPPED ] Sync2Test.OwnershipTranfersBuffer
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] DecompressionTest.DecompressMemory
[  FAILED  ] DecompressionTest.DecompressMemoryIndirect

 2 FAILED TESTS

You can duplicate this issue by running a manual-Vulkan-ExtensionLayer test, then selecting tcubuand2 as the NODE, and putting --devices pixel_7 into the ARGS option so it only runs on the pixel 7.
Test run link: http://tcubuser:8080/view/Manual/job/manual-Vulkan-ExtensionLayer/15/artifact/vulkantest-results/Pixel_7-33301FDH2005F6/out.txt

FYI @vkushwaha-nv

Testing passes on a GalaxyS22 so the bug isn't as simple as not working on Android.

Was this recently enabled? Trying to understand why wasn't this seen before.

Was this recently enabled? Trying to understand why wasn't this seen before.

The LunarG CI is being updated with a newer Android device. This issue was found on the pixel7 which is the newer device.

Can you please attach or email me the full failing log with additional logging enabled?
see in decompresison.cpp on how to turn on logging :
#define kLayerSettingsLogging "logging"
or
static bool logging_enabled = false;

[==========] Running 17 tests from 3 test suites.
[----------] Global test environment set-up.
[----------] 14 tests from Sync2Test
[ RUN      ] Sync2Test.OwnershipTranfersImage
/home/lunarg/.jenkins/mel/Vulkan-ExtensionLayer/tests/synchronization2_tests.cpp:120: Skipped
             TEST SKIPPED:Required queue families not present (non-graphics capable required).

[  SKIPPED ] Sync2Test.OwnershipTranfersImage (18 ms)
[ RUN      ] Sync2Test.OwnershipTranfersBuffer
/home/lunarg/.jenkins/mel/Vulkan-ExtensionLayer/tests/synchronization2_tests.cpp:174: Skipped
             TEST SKIPPED:Required queue families not present (non-graphics capable required).

[  SKIPPED ] Sync2Test.OwnershipTranfersBuffer (19 ms)
[ RUN      ] Sync2Test.SecondaryCommandBufferBarrier
[       OK ] Sync2Test.SecondaryCommandBufferBarrier (19 ms)
[ RUN      ] Sync2Test.SecondaryCommandBufferImageLayoutTransitions
[       OK ] Sync2Test.SecondaryCommandBufferImageLayoutTransitions (19 ms)
[ RUN      ] Sync2Test.QueueSubmitSemaphoresAndLayoutTracking
[       OK ] Sync2Test.QueueSubmitSemaphoresAndLayoutTracking (16 ms)
[ RUN      ] Sync2Test.CommandBufferSimultaneousUseSync
[       OK ] Sync2Test.CommandBufferSimultaneousUseSync (14 ms)
[ RUN      ] Sync2Test.BarrierLayoutToImageUsage
[       OK ] Sync2Test.BarrierLayoutToImageUsage (19 ms)
[ RUN      ] Sync2Test.WaitEventThenSet
[       OK ] Sync2Test.WaitEventThenSet (20 ms)
[ RUN      ] Sync2Test.TwoQueueSubmitsSeparateQueuesWithSemaphoreAndOneFenceTwoWFF
[       OK ] Sync2Test.TwoQueueSubmitsSeparateQueuesWithSemaphoreAndOneFenceTwoWFF (16 ms)
[ RUN      ] Sync2Test.TwoSubmitInfosWithSemaphoreOneQueueSubmitsOneFence
[       OK ] Sync2Test.TwoSubmitInfosWithSemaphoreOneQueueSubmitsOneFence (17 ms)
[ RUN      ] Sync2Test.ClearDepthStencilWithValidRange
[       OK ] Sync2Test.ClearDepthStencilWithValidRange (15 ms)
[ RUN      ] Sync2Test.QueueSubmitTimelineSemaphore
[       OK ] Sync2Test.QueueSubmitTimelineSemaphore (13 ms)
[ RUN      ] Sync2Test.SwapchainImage
[       OK ] Sync2Test.SwapchainImage (35 ms)
[ RUN      ] Sync2Test.EnumerateDeviceExtensionProperties
[       OK ] Sync2Test.EnumerateDeviceExtensionProperties (14 ms)
[----------] 14 tests from Sync2Test (262 ms total)

[----------] 1 test from Sync2CompatTest
[ RUN      ] Sync2CompatTest.Vulkan10
[       OK ] Sync2CompatTest.Vulkan10 (12 ms)
[----------] 1 test from Sync2CompatTest (12 ms total)

[----------] 2 tests from DecompressionTest
[ RUN      ] DecompressionTest.DecompressMemory
Memory decompression feature not available in the driver, enabling decompression layer.
Info: subgroupSize 16
Info: bytecodeIndex 5
Info: Memory Heaps/Types:
    Heap 0: Size<PHONE_NUMBER>, Flags 1
    Heap 1: Size 104857600, Flags 1
    Memory Type 0: HeapIndex 0, Flags 7
    Memory Type 1: HeapIndex 0, Flags 11
    Memory Type 2: HeapIndex 0, Flags 17
    Memory Type 3: HeapIndex 1, Flags 33
Info: Using memory index 0 for indirectDispatch Buffer.
Info: vkCmdDecompressMemoryNV: Using VK_LAYER_KHRONOS_memory_decompression layer
Info: vkCmdDecompressMemoryNV: Using VK_LAYER_KHRONOS_memory_decompression layer
/home/lunarg/.jenkins/mel/Vulkan-ExtensionLayer/tests/decompression_tests.cpp:121: Failure
Value of: compareResult == 0
  Actual: false
Expected: true

[  FAILED  ] DecompressionTest.DecompressMemory (592 ms)
[ RUN      ] DecompressionTest.DecompressMemoryIndirect
Memory decompression feature not available in the driver, enabling decompression layer.
Info: subgroupSize 16
Info: bytecodeIndex 5
Info: Memory Heaps/Types:
    Heap 0: Size<PHONE_NUMBER>, Flags 1
    Heap 1: Size 104857600, Flags 1
    Memory Type 0: HeapIndex 0, Flags 7
    Memory Type 1: HeapIndex 0, Flags 11
    Memory Type 2: HeapIndex 0, Flags 17
    Memory Type 3: HeapIndex 1, Flags 33
Info: Using memory index 0 for indirectDispatch Buffer.
Info: vkCmdDecompressMemoryIndirectCountNV: Using VK_LAYER_KHRONOS_memory_decompression layer
/home/lunarg/.jenkins/mel/Vulkan-ExtensionLayer/tests/decompression_tests.cpp:221: Failure
Value of: compareResult == 0
  Actual: false
Expected: true

[  FAILED  ] DecompressionTest.DecompressMemoryIndirect (571 ms)
[----------] 2 tests from DecompressionTest (1163 ms total)

[----------] Global test environment tear-down
[==========] 17 tests from 3 test suites ran. (1441 ms total)
[  PASSED  ] 13 tests.
[  SKIPPED ] 2 tests, listed below:
[  SKIPPED ] Sync2Test.OwnershipTranfersImage
[  SKIPPED ] Sync2Test.OwnershipTranfersBuffer
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] DecompressionTest.DecompressMemory
[  FAILED  ] DecompressionTest.DecompressMemoryIndirect

 2 FAILED TESTS

To be able to update the CI on this repository to the Pixel 7 device, the test for this layer has been added to a blacklist to prevent it from running.

Note these tests also fail on MacOS with MoltenVK.

You'll need to remove the skips added explicitly for MacOS. Currently testing skips decompression layer testing if it detects the portability  layer.


Support ViewMethod batching

When doing successive RPC calls a major speedup can be achieved by using BatchedTransport and executing multiple requests in a single roundtrip.
At the moment BatchTransport is not well supported by ethcontract-rs. Creating a new instance with batched transport is cumbersome as we have to flush it before we can successfully await the instance (with a risk of deadlock)
let instance_future = Instance::deployed(&batched_transport); // if we await here we deadlock since deployed requires to make a RPC call
batched_transport.submit_batch.await;
let instance = instance_future.await;

I also ran into issues executing calls on this batched transport instance. Since call futures are lazily initialized, we need to poll them once before they enqueue their RPC requests onto the batched transport. Only then can we flush the batched transport and afterwards await the original futures.
A better more integrated approach to support batching would probably involve making it part of a separate API. This API could probably be limited to ViewMethods, as "real" transactions don't really gain that much from being batched on the transport layer (confirmation is usually much longer than roundtrip time, no guarantees that batched txs end up in same block, dependent RPC calls e.g. to estimate gas_limit/gas_price might be necessary).
My suggestion would be to expose a call_in_batch(batch_transport) method on ViewMethodBuilder which instead of calling self.web3.eth().call(...) would invoke batch_transport.eth().call(...) and would return a future that as soon as polled, first awaits the batch_transport.submit_batch() future which should ensure that the original request (that was enqueued in the batch transport) can be polled afterwards. At the same time it allows customers to collect multiple calls before awaiting on the results.
We could also make the customer responsible for calling batch_transport.submit_batch(), however my worry would be that this could lead to deadlocks if one awaits a call before awaiting submit_batch().

I think this issue is implemented and can be closed.


Left-over issues template reorder and small changes

[ ] Something is wrong in the indentation of the tasks here
[ ] A few more items is probably a good idea. And space between [ ] was missing.
[ ] Also reorder: first tasks, then use cases then related pull requests.

Maybe also change the input field to a text area where autocompleting PR's by # works.

Thx for splitting up the issues.


Unable to click on stars in React testing library.

How can i clicks on the star rating. I tried so much.

             <Rating               initialValue={rating}               onClick={handleRating}               fillColor={surveyTheme?.mainThemeColor || "#F1A900"}               fillIcon={                 <RxStarFilled                   size={50}                   aria-label="filled-stars"                   role="button"                 />               }               emptyIcon={                 <RxStar                   size={50}                   color={surveyTheme?.mainThemeColor || "#F1A900"}                   aria-label="unfilled-stars"                   role="button"                 />               }               allowHover={false}               aria-label="ranking-stars"               as="button"             />

AFAIK, The pointerMove event is being used to keep track of the hoverValue, and then the click event is used to save the hoverValue.
The following series of events can be used to simulate the rating change using the react testing library.
...
const ratingStar = getByRole('rating').querySelector('.star-svg');
const ratingContainer = getByRole('rating').querySelector('.react-simple-star-rating'),

fireEvent.pointerMove(ratingStar);
fireEvent.click(ratingContainer);
...

    <Rating onClick={...} />

I don't think @Parassharmaa's code works, or at least I couldn't make it work with cypress.
The problem here is that cypress uses CSS selectors to access things to click on or move over.
So from:

  <Rating onClick={starPickerChange} initialValue={sco} readonly={!loggedin} iconsCount={10} size={24} />

you actually get the following in the DOM.  Each svg has a path but I've excluded them here for brevity.

            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>

            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>
            <svg class="star-svg" stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" width="24" height="24" xmlns="http://www.w3.org/2000/svg"/>

For an annoying moment you can see both sets of stars at the same time, 10 empty next to 10 full, then it snaps to the correct number of filled stars. You have to add a time delay to wait for that to finish before you can move, that's the first problem.
Second problem is that you don't know which star out of the 10-on and 10-off you need to pick and if you pick the wrong one then it hangs the testing framework until it times out.
So for clarity, doing this will only work if the number 8 is not selected.
cy.get('.react-simple-star-rating .empty-icons :nth-child(8)').trigger('pointermove')

and doing this will only work if number 8 is already selected:
cy.get('.react-simple-star-rating .filled-icons :nth-child(8)').trigger('pointermove')

I thought I could just use a selector that will trigger on both, but it obviously doesn't make any sense to have a mouse move on 2 elements at the same time, so cypress complained about that.
Hopefully you can see the problem now. filled-icons and empty-icons exist in the DOM with no indication which is selected.
I've been trying to get this working for most of the afternoon and I'm stuck, so I'm going to add something to the onClick to update a hidden input and read it from there instead. But even then I have to calculate if the star is on or off depending on the number and pick the right class name for the selector. This is way more complicated than it needs to be!!!
Or does anyone know a better way? Or even a way to know how many stars are selected? Help!!

I came across this issue and @davidnewcomb solution did not work for me. For context i'm using react-testing-library with vitest and happy-dom.
After looking at the source code I narrowed it down to two problems:

the handlePointerMove function within Rating was making a getBoundingClientRect() call:
const { left, right, width } = currentTarget.children[0].getBoundingClientRect();
which returned 0s in my testing suite for those attributes. To fix this i mocked it within my test via window.HTMLElement.prototype.getBoundingClientRect = () => ({ width: 100, left: 0, right: 100 }) as DOMRect.
I needed to ensure a clientX value was provided in the pointer move event, like so: await userEvent.pointer({ target: svgStar, coords: { clientX: 30 } }).

With both of these changes I could effectively mock the user interaction via a pointer move event and a subsequent click on the parent container.


7.0.2 version is raising "uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState"

Hi,
In our project, we are not directly using activesupport, but grape does. This is fetching latest version of activesupport, which is currently 7.0.2.
Problem
Starting up the application is raising the following exception:
NameError:
  uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:184:in `current_thread_backend'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:103:in `backend='
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:201:in `<module:ActiveSupport>'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:11:in `<top (required)>'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/core_ext/array/conversions.rb:3:in `require'
# /usr/local/bundle/gems/activesupport-7.0.2/lib/active_support/core_ext/array/conversions.rb:3:in `<top (required)>'
...

Gemfile.lock
specs:
    activesupport (7.0.2)
      concurrent-ruby (~> 1.0, >= 1.0.2)
      i18n (>= 1.6, < 2)
      minitest (>= 5.1)
      tzinfo (~> 2.0)
      zeitwerk (~> 2.3)
# ...
    grape (1.6.2)
      activesupport
      builder
      dry-types (>= 1.1)
      mustermann-grape (~> 1.0.0)
      rack (>= 1.3.0)
      rack-accept

...
Potential fix
Shouldn't constant ActiveSupport::XmlMini::IsolatedExecutionState be ActiveSupport::IsolatedExecutionState as found in xml_mini.rb?
Temporary solution on our place
We have forced our Gemfile to contain active_support fixed to working version 6.1. This is a workaround, as we are adding a dependency we are not using in our own codebase, but as a subdependency.

Was this fixed in https://github.com/ruby-grape/grape/pull/2208?
I am not seeing Rails 7 in https://github.com/ruby-grape/grape/blob/master/.github/workflows/test.yml#L40. Can you please PR that and let's see what breaks and fix it?

Was this supposedly fixed in #2208 and released in 1.6.1? @ericproulx
Either way I'd try to reproduce this in a spec/Gemfile/Appraisal.

It was supposed to be fix. I'll check

@immccc could you provide a complete Gemfile.lock. I couldn't reproduce with a brand new rails app. Thanks

Hi @ericproulx , thanks for taking a look!
Sorry, but unfortunately can't share full Gemfile.lock since I'd have to do a lot of cherry-picking, removing internal/confidential packages. Anyhow, the dependencies pointing to activesupport are just the ones I exposed when I opened the issue and I don't think you'll find relevant information on there.
I checked fetched sources from activesupport v7.0.2 gem and problem can be seen easily:

From the above snapshots, IsolatedExecutionState is assumed to be in the same path than XmlMini, which is ActiveSupport::XmlMini. However, it's actual path is ActiveSupport.
__
In addition, I think I didn't explain myself about how to reproduce the issue:

We made a fresh new grape app.
After bundle install, grape declares a dependency to activesupport (as shown in the top comment)
The fetched activesupport version is 7.0.2.
When starting the grape server, app launches the error posted in top comment.

Hope that helps.

@immccc Can you please make a trivial application that reproduces this and put it up on GitHub or make a PR with a spec that fails here?

@dblock I don't think that's needed. In order to check what's happening here, just check which version of avtivesupport is fetching Grape 1.6.2. And if it's 7.0.2, bingo!
Also please take a look to linked snapshots from my comment above, where you can see how reference used to IsolatedExecutionState is not matching to its declaration.
Thanks!

Also please take a look to linked snapshots from my comment above, where you can see how reference used to IsolatedExecutionState is not matching to its declaration.

This is how Constant resolution works in Ruby, there is nothing suspicious.

The provided logs does not contain the full trace path so it's not clear that's going on on your side.

@immccc yes I can debug the issue, reproduce and probably fix it and so can @ericproulx who fixed it in the first place, but that will take some unknown amount of time given that nobody is paid to do this work. So help us help you so we can do this faster?
Turn the problem into an integration test with the locked version of ActiveSupport that demonstrates the issue and PR it. And maybe you'll find out what the problem is and fix it yourself!

@dblock no worries, I'll test a "hello world" and come back with it when I have some time.

This happens when for instance if, in your project, you do require 'active_support/core_ext/object' without requiring require 'active_support' first. The require require 'active_support' is needed to do some initialisation for active_support.

@lvonk yeah, and this was fixed in https://github.com/ruby-grape/grape/pull/2206.

But that was in 1.6.1, and the report above says 1.6.2?

Sorry for coming back late. Just tried to reproduce locally on a Grape app from scratch (I'm using https://github.com/zachrab/grape-hello-world )
This time, after removing original Gemfile.lock and bundle install, ActiveSupport is pointing to version <IP_ADDRESS>. It's running fine. I forced to have version 7.0.2 and still working fine.
Not sure why I cannot reproduce, as the other project was not making active use of ActiveSupport.

But that was in 1.6.1, and the report above says 1.6.2?

I'm not sure what you mean by that. Shouldn't this be fixed in 1.6.2 too?

I'm closing, it looks unrelated to grape, it might be some other dependency. Feel free to provide a stack trace with the lines that point to the grape and re-open.
Meanwhile:
require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'grape', '1.6.2'
  gem 'activesupport', '7.0.2'
end

puts 'It works!'

It works!

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'grape', '1.6.0'
  gem 'activesupport', '7.0.2'
end

puts 'It works!'

Traceback (most recent call last):
        17: from test_grape.rb:3:in `<main>'
        16: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/inline.rb:55:in `gemfile'
        15: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/settings.rb:131:in `temporary'
        14: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/inline.rb:71:in `block in gemfile'
        13: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/runtime.rb:50:in `require'
        12: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/runtime.rb:50:in `each'
        11: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/runtime.rb:61:in `block in require'
        10: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/runtime.rb:61:in `each'
         9: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/runtime.rb:66:in `block (2 levels) in require'
         8: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/bundler-2.2.23/lib/bundler/runtime.rb:66:in `require'
         7: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/grape-1.6.0/lib/grape.rb:15:in `<top (required)>'
         6: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/grape-1.6.0/lib/grape.rb:15:in `require'
         5: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/activesupport-7.0.2/lib/active_support/core_ext/array/conversions.rb:3:in `<top (required)>'
         4: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/activesupport-7.0.2/lib/active_support/core_ext/array/conversions.rb:3:in `require'
         3: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:11:in `<top (required)>'
         2: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:201:in `<module:ActiveSupport>'
         1: from /Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:103:in `backend='
/Users/dmitrydedov/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/activesupport-7.0.2/lib/active_support/xml_mini.rb:184:in `current_thread_backend': uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionSt
ate (NameError)