Conversation
Add a new POST /publish API endpoint that allows publishing custom oracle data on-chain immediately, bypassing the regular updateInterval. The endpoint accepts a JSON payload with oracle data items, builds and submits a recreate transaction, and returns the transaction hash synchronously. Key components: - ImmediatePublishRequest/Response message types for actor communication - Global actor registry to route API requests to chain-event-processor - handleImmediatePublish method with full trie diff, cloud upload, and tx flow - Input conflict detection to prevent double-spend with pending transactions - 60-second timeout on the synchronous response channel
…ale loop After a successful immediate publish, the old validator UTxO is consumed. Without clearing the cached reference, the regular publish flow would reuse the stale UTxO and fail repeatedly until the cache expired.
Persist publish records to the database when data is published via the immediate publish endpoint, tracking pending→confirmed status transitions. Adds GET /publish/history with filters (object_id, tx_hash, date range) and DISTINCT ON deduplication for latest-per-object default view. Components: - PublishRecord model with GORM tags and indexes - CreatePublishRecords/ConfirmPublishRecords database methods - QueryPublishHistory with expand_history toggle and pagination - Swagger docs regenerated for the new endpoint
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5e3c286158
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| case types.ImmediatePublishRequest: | ||
| metrics.RecordActorMessage("ChainEventProcessor", "ImmediatePublishRequest") | ||
| s.logger.Infow("received ImmediatePublishRequest", "data_count", len(msg.Data)) | ||
| go s.handleImmediatePublish(msg) |
There was a problem hiding this comment.
Launching handleImmediatePublish in a goroutine breaks the actor’s single-threaded execution model. The handler reads actor fields like lastSuccessfullyIndexedBlockNum/lastSuccessfullyIndexedSlot and uses other actor-owned resources while Receive may be mutating them concurrently during block processing. This introduces data races and can lead to inconsistent publish behavior under concurrent requests. Consider handling the publish request synchronously in the actor loop or copying the needed state into the request before starting a goroutine, with proper synchronization.
Useful? React with 👍 / 👎.
1 participant
No description provided.