feat: add informative REST results for TAKE failures (SOFIE-295)

[anteeek]

About the Contributor

This PR is made on behalf of the BBC

Type of Contribution

This is a:

Feature

Current Behavior

The TAKE endpoint returns either 200 or 500, without any additional information

New Behavior

HTTP Rest codes 400, 425 and 429 are added as possible failure reasons, and a UTC timestamp for next possible take is added

Testing

• I have added one or more unit tests for this PR
• I have updated the relevant unit tests
• No unit test changes are needed for this PR

Affected areas

the TAKE endpoint

Time Frame

Not urgent, but we would like to get this merged into the in-development release.

Other Information

Status

• PR is ready to be reviewed.
• The functionality has been tested by the author.
• Relevant unit tests has been added / updated.
• Relevant documentation (code comments, system documentation) has been added / updated.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

• 🔍 Trigger a full review

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Important

Action Needed: IP Allowlist Update

If your organization protects your Git platform with IP whitelisting, please add the new CodeRabbit IP address to your allowlist:

• ✨ 136.113.208.247/32 (new)
• 34.170.211.100/32
• 35.222.179.152/32

Reviews will stop working after February 8, 2026 if the new IP is not added to your allowlist.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[anteeek]

Note: this PR was first created with wrong target in bbc#64

[codecov]

Codecov Report

❌ Patch coverage is 37.50000% with 30 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
packages/job-worker/src/playout/take.ts	28.57%	25 Missing ⚠️
meteor/server/api/rest/v1/playlists.ts	0.00%	3 Missing ⚠️
meteor/server/lib/rest/v1/playlists.ts	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Julusian]

I feel like the openapi definitions should be updated to reflect this addition?

I don't see how the time is being reported for non-200 status codes. Unless the nextAllowedTakeTime inside the UserError is being reported somehow?

[anteeek]

@Julusian addressed the comment, thanks! Please take a look when you can

[Julusian]

I'm not keen on this.

If its going to be a concept that we have defined in the client api, then it should be a proper concept in the UserError too.

But I'm not sure if it should be a dedicated value in ClientResponseError either.
I don't have any suggestions on how to do this better though, it just feels smelly to have this value specific to one UserAction be present in what is otherwise very general code

[Julusian]

I suppose I wouldnt mind if on UserError has an explicit property for nextAllowedOperationTime, and that was on ClientResponseError too. (or something named more around being a rate limit)

Then at least it is more generic and could be used by other things too (even though it wont for now, but maybe there should be more cases where we 'rate limit')

In the api it can continue to call it nextAllowedTakeTime, I am just worried about the specific naming of something for a single UserAction on internal types (if every action did that, these types would become a confusing mess