Finding
The current Stellar documentation surface can lead a bot author to rely on
Horizon offer_created, offer_updated, and offer_removed effects for SDEX
offer lifecycle tracking. Current stellar/go marks effect types 30/31/32
unused, and a live successful offer update returned no Horizon effects even
though its transaction result carried the updated OfferEntry.
The missing operational boundary is narrow: these effect types are not a
current lifecycle feed. Transaction result XDR/meta records the offer outcome,
while Horizon's open-offer and trade resources answer separate current-state
and history questions.
Evidence
On 2026-07-10, manage-buy-offer operation 272376861589106689 successfully
updated offer 1847875879. Its Horizon effects collection was empty, while
decoded TransactionResult XDR contained the updated offer entry. Separately,
offer 1848272936 returned 404 after fills while its offer-trades endpoint
returned two trades.
Current source corroborates the behavior:
stellar/go/protocols/horizon/effects/main.go comments offer effect types
30/31/32 as unused while trade effect 33 remains active;
stellar/go/toid/synt_offer_id.go explains synthetic IDs for immediately
filled offers; and
- stellar-core result XDR records CREATED/UPDATED/DELETED plus claimed offers.
This is a docs-content/behavior gap, not an Algolia ranking issue.
Additional recorded evidence:
- stellar/go protocols/horizon/effects source at aab2ea4 marks offer-created/updated/removed effect types unused
- live successful manage-buy-offer operation 272376861589106689 returned zero effects while TransactionResult XDR contained the updated OfferEntry
- removed offer 1848272936 returned 404 while its offer-trades endpoint retained two trades
- rechecked 2026-07-14: current Effect Types docs still list the three offer effects, while current stellar/go keeps types 30/31/32 commented as unused
Recommendation
In the Effect Types table, mark offer-created/updated/removed as unused rather
than listing them as emitted effects. Add one adjacent lifecycle note that
directs readers to transaction result XDR/meta for the operation outcome, and
to open-offer/trade resources for current state and retained trade history.
Source Record
This was found by the downstream Raven eval/improvements loop and recorded as sd-011 (stellar-docs, discovered 2026-07-10).
Public source record: improvements/stellar-docs/sd-011-sdex-offer-effects-lifecycle-stale.md
Immutable source snapshot: bbb0d4f55527
Resolution Handoff
When a fix is deployed, please link the resolving issue or PR to the source record above and notify Raven through:
https://github.com/kalepail/stellar-raven/issues/new?template=upstream-improvement-ready.yml&title=%5Bupstream-ready%5D%20sd-011%3A%20
Include the finding id, resolving issue/PR, deployed version or timestamp, and the smallest live recheck. Raven independently verifies the upstream surface before changing the finding to fixed-upstream; issue closure or a merged PR alone is not treated as proof. After a distinct reviewer repeats the live check, the active finding is retired to Raven's resolved ledger while the immutable snapshot remains available.
Finding
The current Stellar documentation surface can lead a bot author to rely on
Horizon
offer_created,offer_updated, andoffer_removedeffects for SDEXoffer lifecycle tracking. Current
stellar/gomarks effect types 30/31/32unused, and a live successful offer update returned no Horizon effects even
though its transaction result carried the updated
OfferEntry.The missing operational boundary is narrow: these effect types are not a
current lifecycle feed. Transaction result XDR/meta records the offer outcome,
while Horizon's open-offer and trade resources answer separate current-state
and history questions.
Evidence
On 2026-07-10, manage-buy-offer operation
272376861589106689successfullyupdated offer
1847875879. Its Horizon effects collection was empty, whiledecoded TransactionResult XDR contained the updated offer entry. Separately,
offer
1848272936returned 404 after fills while its offer-trades endpointreturned two trades.
Current source corroborates the behavior:
stellar/go/protocols/horizon/effects/main.gocomments offer effect types30/31/32 as unused while trade effect 33 remains active;
stellar/go/toid/synt_offer_id.goexplains synthetic IDs for immediatelyfilled offers; and
This is a docs-content/behavior gap, not an Algolia ranking issue.
Additional recorded evidence:
Recommendation
In the Effect Types table, mark offer-created/updated/removed as unused rather
than listing them as emitted effects. Add one adjacent lifecycle note that
directs readers to transaction result XDR/meta for the operation outcome, and
to open-offer/trade resources for current state and retained trade history.
Source Record
This was found by the downstream Raven eval/improvements loop and recorded as sd-011 (stellar-docs, discovered 2026-07-10).
Public source record: improvements/stellar-docs/sd-011-sdex-offer-effects-lifecycle-stale.md
Immutable source snapshot: bbb0d4f55527
Resolution Handoff
When a fix is deployed, please link the resolving issue or PR to the source record above and notify Raven through:
https://github.com/kalepail/stellar-raven/issues/new?template=upstream-improvement-ready.yml&title=%5Bupstream-ready%5D%20sd-011%3A%20
Include the finding id, resolving issue/PR, deployed version or timestamp, and the smallest live recheck. Raven independently verifies the upstream surface before changing the finding to
fixed-upstream; issue closure or a merged PR alone is not treated as proof. After a distinct reviewer repeats the live check, the active finding is retired to Raven's resolved ledger while the immutable snapshot remains available.