Reuse client in the second round of the JWT fetch#57
Reuse client in the second round of the JWT fetch#57tnull merged 1 commit intolightningdevkit:mainfrom
Conversation
As Matt notes in lightningdevkit#56, `fetch_jwt_token` may be called on startup/wallet init and may be in the critical path for the first wallet UI paint, so its incredibly latency-sensitive.
|
👋 Thanks for assigning @tnull as a reviewer! |
| let lnurl_request = bitreq::get(&self.url) | ||
| .with_headers(self.default_headers.clone()) | ||
| .with_timeout(DEFAULT_TIMEOUT_SECS) | ||
| .with_max_body_size(Some(MAX_RESPONSE_BODY_SIZE)); |
There was a problem hiding this comment.
If we consider it that latency critical, we probably want to enable piplining for these?
There was a problem hiding this comment.
I hesitate mostly because the server might only want to issue a single JWT token over the course of say 24 hours for a particular public key. Is that reasonable ? So in the second round, the server might refuse to return the JWT on the second try.
There is also the fact that we could get different k1's back from the first call, so not quite idempotent, but this may be ok here.
There was a problem hiding this comment.
It won't matter because we have to wait for the first response before we can send the second request, so either way its serial.
4 participants
As Matt notes in #56,
fetch_jwt_tokenmay be called on startup/wallet init and may be in the critical path for the first wallet UI paint, so its incredibly latency-sensitive.