GET /ready never populates last_price_cycle_secs_ago / last_keeper_cycle_secs_ago on success, unlike /health — and an existing test locks in the gap

[abayomicornelius]

File(s): oracle/src/api/prices.rs:69-160 (ready), compare :20-61 (health); existing test asserting the None values (~line 293-294)

Problem:
health() in oracle/src/api/prices.rs computes last_price_cycle_secs_ago/last_keeper_cycle_secs_ago correctly from cycle (lines ~46-61) and returns them. ready(), a few lines below, already reads the same state.cycle_status to run its own staleness checks — but both of its success-response branches (the 3-second-TTL cache-hit path around line 124-125, and the fresh-check success path around line 153-154) hardcode last_price_cycle_secs_ago: None, last_keeper_cycle_secs_ago: None instead of using the values already in scope. This isn't just untested — an existing test explicitly asserts body.last_price_cycle_secs_ago.is_none() and the keeper equivalent, actively locking in the gap as expected behavior rather than catching it.

Suggested fix:
Populate last_price_cycle_secs_ago/last_keeper_cycle_secs_ago in ready() using the same cycle read already performed, in both the cached and fresh-check success paths, and update the test to assert the real values instead of None.

Acceptance Criteria:

• A successful /ready response includes non-null last_price_cycle_secs_ago and last_keeper_cycle_secs_ago
• The existing test asserting these fields are None is updated to assert real values

[Yasir-TechGuy]

@Yasir-TechGuy has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Please assign this issue to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Yasir-TechGuy to this issue.

[Lazaruster]

@Lazaruster has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Hello Maintainer, I would love to work on this issue, please assign it to me!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Lazaruster to this issue.

[sunnykid-02]

@sunnykid-02 has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

I’d like to work on this issue because accurate readiness metrics are essential for monitoring and operating production systems. If GET /ready never populates last_price_cycle_secs_ago, it reduces the usefulness of the readiness endpoint and can make it harder to detect stale pricing data or diagnose issues with the price update pipeline.

I have experience working with backend APIs, health and readiness endpoints, observability, and debugging state propagation issues.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @sunnykid-02 to this issue.