Failed to authenticate with Ledger API

Questions
1

i am using extractor to extract all the contract data of a user but getting following error.

Failed to authenticate with Ledger API on attempt 1, next one in 1 second

**

upload
upload1920Ă—1080 145 KB
**

1 Like
2

I’m not 100% sure, but I think you’ll need to provide an access token via the --access-token-file parameter. To get a default token that’s accepted by the sandbox you can use https://jwt.io/ . Enter the following payload (assuming ledger-id test here, change that to whatever you’re using):

{
   "https://daml.com/ledger-api": {
     "ledgerId": "test",
     "participantId": null,
     "applicationId": null,
     "admin": true,
     "actAs": ["Validator"],
     "readAs": ["Validator"]
   },
   "exp": 1999999999
}

and use secret as the secret. You can use this link and adjust the payload to your needs.

Put that into a file, eg token.txt and run the extractor with --access-token-file=token.txt. Can you try that and see if it works?

3 Likes
3

Even after using token file, I am getting the same error and also do I have to create table as specified in [docs] (https://docs.daml.com/tools/extractor.html#transactions) of Transaction, Contract etc or it automatically create while extracting.

1 Like
4

It could be that you have to prefix the token in the file with Bearer so your token.txt looks like this:

Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwczovL2RhbWwuY29tL2xlZGdlci1hcGkiOnsibGVkZ2VySWQiOiJ0ZXN0IiwicGFydGljaXBhbnRJZCI6bnVsbCwiYXBwbGljYXRpb25JZCI6bnVsbCwiYWRtaW4iOnRydWUsImFjdEFzIjpbIlZhbGlkYXRvciJdLCJyZWFkQXMiOlsiVmFsaWRhdG9yIl19LCJleHAiOjE5OTk5OTk5OTl9.ARSLC2BdbRpM1goMyae_vpbyVf6e4CH3q1epfJKrTPQ

If that doesn’t work, can you paste the content of your token.txt (assuming it’s for testing only) here so I can validate it?

1 Like
5

Extractor does not require a dummy token like the JSON API. If it complains about needing a token it is because your ledger is actually running with authentication and it will validate your token. In that case, you can only use secret as the secret if you started sandbox with --auth-jwt-hs256-unsafe=secret. If you used another secret you will have to change it and if you used one of the --auth-jwt-es256-crt-like flags you will have to use the correspond algorithm when creating your token.

2 Likes
6

Note that this is true only for versions before 1.0.0. The schema has been set to Bearer and it doesn’t have to be prefixed in token files. This is the PR that introduced the change for a few components of the SDK, including Extractor.

1 Like
7

i didn’t use any auth-jwt while starting sandbox as you can see in image

second
second1920Ă—1080 188 KB

1 Like
8

I have had a better look at the output of the first screenshot you shared (hint: you can use code snippets to make shared logs easier to read :wink: ) and it looks like extractor has shown a spurious error but completed its task successfully. Can you have a look at the database and confirm, please?

3 Likes
9

I looked into database tables but each one is empty only schema is created.

1 Like
10

And if you have a look at Navigator using Validator as a party, do you see active or archived contracts?

1 Like
11

tl;dr the error you see is spurious but not fatal, if you don’t see the expected data on Extractor the cause is something else.

As further information: that message definitely looks wrong and we should look into why that’s happening, but please note that Extractor will keep retrying to connect to a Ledger API server protected by authentication indefinitely, so if you only see that message once it should be something you’re aware of but not a fatal error. You can expect that to happen if you are working against a Ledger API server protected by authentication and the key rotation is delayed or doesn’t work.

1 Like
12

Yes, Extractor is continuously trying to connect and giving following error each time.

14:40:49.400 INFO  c.d.a.TokenHolder@[kka.actor.default-dispatcher-6] - Reading token from token.txt...
14:40:49.401 INFO  c.d.e.Extractor@[kka.actor.default-dispatcher-6] - Starting streaming transactions from Absolute(000000000000000f0000000000000000)...
14:40:49.424 WARN  a.s.s.RestartWithBackoffSource@[kka.actor.default-dispatcher-7] - Restarting graph due to failure. stack_trace: 
io.grpc.StatusRuntimeException: INVALID_ARGUMENT: Invalid argument: Begin offset 000000000000000f0000000000000000 is after ledger end 000000000000000a0000000000000000
	at io.grpc.Status.asRuntimeException(Status.java:533)
	at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:442)
	at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
	at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
	at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
	at io.grpc.internal.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:700)
	at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
	at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
	at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
	at io.grpc.internal.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:399)
	at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:507)
	at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:66)
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:627)
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$700(ClientCallImpl.java:515)
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:686)
	at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:675)
	at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
	at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
1 Like
13

Ok, a couple of notes: if you are not running daml start specifying that you want to run in authenticated mode, do not pass in a token file (the log shows that you are passing token.txt).

Regarding the error you see, I believe that might be a bug, I’ll check it. In the meantime, would you mind checking if you still see the error if you run daml start --sandbox-classic?

2 Likes
14

I’ll need to have more details regarding your setup because the error you are seeing is very weird and it seems to point at several restarts using the same persistent backend using different SDK versions.

  1. what SDK version are you using?
  2. are you using sandbox or sandbox-classic? daml start and daml sandbox run sandbox-classic by default up until version 0.13.55 included and sandbox starting from version 1.0.0
  3. are you using some form of persistent backend (i.e. --sql-backend-jdbcurl) when you run daml start or daml sandbox?
  4. if yes, have you been using the same persistent backend across SDK upgrades?

Please do add as many details as possible and don’t stop at providing the details I asked explicitly, the more details the easier it’ll be for me to investigate and the quicker you’ll have an answer. :wink:

2 Likes
15

Thanks @stefanobaghino-da sorry I was little bit confused by the authentication error but after removing token file I am still seeing the
15:56:35.106 ERROR c.d.e.Extractor@[ka.actor.default-dispatcher-12] - Failed to authenticate with Ledger API on attempt 1, next one in 1 second

but finally, all party contract detail is extracted from the ledger and stored in Postgres table. Thanks again

2 Likes