DurableEmitter: Refactor with Chip BatchEmitter#2090
Conversation
|
005ca74 to
fad5397
Compare
…ontractkit/chainlink-common into CRE-4422-refactor-durable-emitter
| ) | ||
|
|
||
| const ( | ||
| authHeaderKey = "X-Beholder-Node-Auth-Token" |
There was a problem hiding this comment.
Note: This file is just example code to show what we would need to do to achieve similar behaviour to beholder for injecting signer post initialization
There was a problem hiding this comment.
@pkcll for some context - the rotating signer works today, but we can do better by upgrading to per message auth for ChIP as there is no passthrough.
If, however, we believe that a streaming API is the best long term path for the durable emitter, than the rotating auth will be useful as generating a hash poses concurrency challenges.
There was a problem hiding this comment.
upgrading to per message auth for ChIP
Signing every message adds CPU/latency on the publish hot path. Rotating signer is sufficient and gives us enough security IMHO.
There was a problem hiding this comment.
New commit seems simple enough for me.
Collapse pkg/durableemitter/auth.go onto chipingress.NewHeaderProvider, removing the duplicated static/rotating header provider, newAuthHeaderV2, and auth header constants. Keep a thin lazySigner wrapper plus the package-level SetGlobalSigner/IsGlobalSignerSet so LOOP plugins can still inject the CSA keystore after startup. NewAuthHeaderProvider now wraps the (possibly nil) signer in the lazy holder, delegates provider construction to chipingress, and publishes the wrapper globally only for rotating auth. setup.go and the existing call sites are unchanged.
9e20e32 to
48205bc
Compare
|
@patrickhuie19 @DylanTinianov, I pushed this commit please review |
Refactors Durable Emitter to use Batch Emitter for publishing to Chip and includes the following changes:
globalEmitterfor accessability (similar to beholder client)Core Integration PR