Skip to content

feat: Allow passing X-Actor-Request-ID via charge() method - #1162

Merged
janbuchar merged 3 commits into
masterfrom
apify-request-id
Oct 21, 2026
Merged

janbuchar merged 3 commits into
masterfrom
apify-request-id

Conversation

@janbuchar

Copy link
Copy Markdown
Contributor

@janbuchar janbuchar added adhoc Ad-hoc unplanned task added during the sprint. t-tooling Issues with this label are in the ownership of the tooling team. labels Oct 19, 2026
@janbuchar
janbuchar requested a review from barjin October 19, 2026 13:59
Comment thread src/resource_clients/run.ts Outdated
count,
idempotencyKey: providedIdempotencyKey,
timeoutSecs = 'short',
apifyRequestId: requestId,

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would requestId by itself be clear enough? @patrikbraborec @tobice

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, without context, I would be little bit confused. But what are the alternatives?

apifyServerRequestId?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. requestId — exactly what we pass in the JSON request body of the charge endpoint
  2. apifyRequestId — current state of the PR
  3. apifyServerRequestId — what you just suggested

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would vote for consistency. The charge endpoint accepts a requestId, so let's have it in the client API as well.

If it's confusing, it's too late to change that on the API anyway 😄

@barjin barjin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you @janbuchar!

I left a few ideas below, I'll leave the final decision on @patrikbraborec 👍

Comment thread src/resource_clients/run.ts Outdated
/** Defaults to runId-eventName-timestamp */
idempotencyKey?: string;
/**
* ID of the request being served by a multi-tenant Standby run, taken from the `X-Apify-Request-ID` header of the incoming request.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the header name is X-Actor-Request-ID (Actor, not Apify) - see source here

@janbuchar janbuchar Oct 20, 2026 •

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems trustworthy, thanks

Comment thread src/resource_clients/run.ts Resolved
Comment on lines 343 to 346
* @param options.eventName - **Required.** Name of the event to charge for.
* @param options.count - Number of times to charge the event. Default is 1.
* @param options.idempotencyKey - Optional key to ensure the charge is not duplicated. If not provided, one is auto-generated.
* @param options.timeoutSecs - Timeout for the API request. Default is `'short'`.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we mention the new param here?

@tobice tobice left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I vote for consistency with API, i.e., requestId.

Also pls update the PR title.

Comment thread src/resource_clients/run.ts Outdated
count,
idempotencyKey: providedIdempotencyKey,
timeoutSecs = 'short',
apifyRequestId: requestId,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would vote for consistency. The charge endpoint accepts a requestId, so let's have it in the client API as well.

If it's confusing, it's too late to change that on the API anyway 😄

@janbuchar janbuchar changed the title feat: Allow passing X-Apify-Request-Id via charge() method feat: Allow passing X-Actor-Request-Id via charge() method Oct 20, 2026
@apify-service-account apify-service-account added the tested Temporary label used only programatically for some analytics. label Oct 21, 2026
@janbuchar janbuchar changed the title feat: Allow passing X-Actor-Request-Id via charge() method feat: Allow passing X-Actor-Request-ID via charge() method Oct 21, 2026
@janbuchar
janbuchar merged commit f821cde into master Oct 21, 2026
13 checks passed
@janbuchar
janbuchar deleted the apify-request-id branch October 21, 2026 14:08
vdusek added a commit to apify/apify-client-python that referenced this pull request Oct 26, 2026
Adds an optional `request_id` argument to `RunClient.charge()` and
`RunClientAsync.charge()`. The client sends it as `requestId` in the
charge request body. A multi-tenant Standby run passes the
`X-Actor-Request-ID` header of the incoming request here, and the
platform bills the event to the caller who made that request.

- Needed by apify/apify-sdk-python#1193
- Counterpart of apify/apify-client-js#1162

*✍️ Drafted by Claude Code*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

adhoc Ad-hoc unplanned task added during the sprint. t-tooling Issues with this label are in the ownership of the tooling team. tested Temporary label used only programatically for some analytics.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants