https://authzed.com logo
Join Discord
Powered by
Running into an interesting issue with
# spicedb
m
Running into an interesting issue with authzed-node when running against an insecure connection, we receive the error: 
Last error: Credentials not loaded
. This is with the latest version of authzed-node, but I'm not sure if it existed with prior as well. Any ideas on this?
Does this mean we should remove the ability to use this insecurely?
Playing around locally, I've found that basically they removed the ability to have both an insecure channel credential and have the metadata/bearer token passed via 
createFromMetadataGenerator
(which does it automatically on every call). To solve it, you have to (1) only use the 
grpc.ChannelCredentials.createInsecure()
type without wrapping it in a 
combineChannelCredentials()
call and then (2) pass the credentials via the 
metadata
property on every individual gRPC call. This works - but would be extremely annoying to use. Any thoughts on a better option?
@ecordell not sure if you've had any experience with this, but it basically means we can't use the JS client with insecure anymore for CI/test stacks
nvm, after digging further I see that this bug was already known and the authzed-nodejs repo had a custom fix for it that broke due to a change in grpc back in July. I submitted a fix at https://github.com/authzed/authzed-node/pull/167
y
thank you for submitting the fix! i'll take a look at it on Tuesday.
m
thanks! 🙏
@yetitwo if you're good with the fix, would you also be able to cut a release today so we can get our CI back up?
y
yeah, i should be able to do that
i do ideally wanna figure out why this wasn't caught by our test suite
m
its likely the same reason it was hidden from us as well. My assumption is that your package.json still points to "@grpc/grpc-js": "^1.11.3" and your yarn.json is locking it to the same version (see https://github.com/authzed/authzed-node/blob/main/yarn.lock#L98). But if you install this dependency in another repo, it may pull the transient dependencies based on the semantic match, which could pull 1.12 which has the breaking change.
y
ahhh that makes sense. i actually have an issue open to get rid of 
yarn.lock
and this is a concrete reason we should do that.
do you know off the top of your head whether that change is backwards-compatible?
m
I do not unfortunately, you should be able to pin the gprc-js version back to 1.11 and leave the empty object 
{}
response in there to see what happens. Fwiw, the class there is just a copy from the grpc-js org, but with logic to allow the non-ssl request over block it
y
dope, sounds good
m
Previously, a 
null
value would be coalesced to an empty object
y
well that's a weird behavior
but yeah sounds good
m
lol yup, seems like they wanted to be more restrictive
y
i was able to repro in our tests by getting rid of lockfiles, and now i'm waiting for tests to run against your PR with the fix
m
awesome, thanks 🙏
y
i'll get that in and then get a release cut
that should be out in 1.0.3. can you pull and let me know if it's happy?
m
I'll check now, thanks
y
thank you!
m
Confirmed that the insecure path does now work. I will be able to check the happy SSL path later today in staging and I can report back
y
sounds good
33 Views
PreviousNext
Powered by