Agent-JS 0.14.0 - AssetManager & Retry logic

Agent-JS 0.14.0 is released today. Prominent features include a new package, @dfinity/assets, automatic retries for failed calls, a new Agent.fetchCandid() interface, and a Agent.syncTime() interface in case a device is out of sync with the replica.

Release is visible here: Release v0.14.0 · dfinity/agent-js · GitHub
Changelog is available at https://agent-js.icp.xyz/changelog.html

8 Likes

For anyone upgrading from auth-client@0.12, there is a breaking change.

@0.12 this worked and opened Internet Identity popup window on mobile browsers:

// onClick triggered function
let client = await AuthClient.create(...)
client.login(...)

After @0.12 you have to create the AuthClient prior/outside of the function calling client.login
I suppose the new create function loses the user initiated event flag and gets your popups blocked.

Just leaving this so others can find the solution faster.

2 Likes

@kpeacock Just ran into this same issue. Confirming that @infu’s fix solves the problem (but it’s not pretty).

As a temporary workaround/hack I’m pre-initializing the AuthClient before any login attempt, and then reinitializing it on logout/disconnect.

The authClient is designed to load any stored identity from storage automatically, so it was designed with the pattern in mind where you just spin it up at page load. It’s not so much a hack as the intended design.

The issue with the added asynchronicity (which was always accounted for in the design) came when we started using IndexedDb in order to securely store ECDSAKeyIdentities using the CryptoKey built-in, which allows your base key to be non-exportable.

It would be possible to offer a more functional approach though - a import {login} from @dfinity/auth-client method that doesn’t worry about loading stored identities, and you could just handle storage / persistence on your own

2 Likes

I bumped into this today and I have to disagree with @icme, I think the pattern feels very good!

Though I am wondering if there’s a baked-in pattern for catching a 400: delegation expired and kicking off an event from then AuthClient so that this case can be gracefully handled in a UI. :thinking:

1 Like

The current mechanism is that we check during create to check if the delegation is expired during start up. If we get it wrong locally, or if the delegation expires during the lifecycle of the page, we don’t have that logic baked in.

We could probably offer an onExpiration callback, and trigger it at the point we’d expect the delegation to expire. Unfortunately, the AuthClient doesn’t have access to the calls, since it passes an Identity that is used by an Agent, used by an Actor.

I had a design at one point where you could register actors with the AuthClient, so they could be invalidated by the IdleManager, and that would support this kind of flow, but I wasn’t happy with the interface or the complexity it added

I think it would be better to expose some new specialized error handling API’s to the HTTPAgent and encourage people to register them

1 Like