Repository navigation
feat: Allow passing X-Actor-Request-ID via charge() method - #1162
Conversation
| count, | ||
| idempotencyKey: providedIdempotencyKey, | ||
| timeoutSecs = 'short', | ||
| apifyRequestId: requestId, |
There was a problem hiding this comment.
Would requestId by itself be clear enough? @patrikbraborec @tobice
There was a problem hiding this comment.
Well, without context, I would be little bit confused. But what are the alternatives?
apifyServerRequestId?
There was a problem hiding this comment.
requestId— exactly what we pass in the JSON request body of the charge endpointapifyRequestId— current state of the PRapifyServerRequestId— what you just suggested
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
thank you @janbuchar!
I left a few ideas below, I'll leave the final decision on @patrikbraborec 👍
| /** 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. |
There was a problem hiding this comment.
I believe the header name is X-Actor-Request-ID (Actor, not Apify) - see source here
There was a problem hiding this comment.
Seems trustworthy, thanks
| * @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'`. |
There was a problem hiding this comment.
Shall we mention the new param here?
tobice
left a comment
There was a problem hiding this comment.
I vote for consistency with API, i.e., requestId.
Also pls update the PR title.
| count, | ||
| idempotencyKey: providedIdempotencyKey, | ||
| timeoutSecs = 'short', | ||
| apifyRequestId: requestId, |
There was a problem hiding this comment.
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 😄
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*
requestIdparam inActor.charge()apify-sdk-js#776