Question
Kaggle API retry limits when a timed-out submission may already count against the daily allowance
Dev Byte
0 reputation · 22 Aug 2020, 07:33 UTC
23.6K views1
Loading…
0 reputation · 22 Aug 2020, 07:33 UTC
When building an automated pipeline around the Kaggle API, a client timeout during a competition submission leaves the write state ambiguous. The request may have been accepted and scored, or it may have failed before recording. Because Kaggle competitions define a per-competition daily submission allowance in their rules rather than a fixed platform-wide constant, an unnecessary retry can consume a scarce resource.
The Kaggle API does not document an idempotency token for submission requests, so a client retry cannot be assumed to be deduplicated by the server. The unresolved behavior is whether the daily allowance is decremented at receipt time or at scoring completion. If it is consumed at receipt, a blind retry after a timeout always costs an extra slot even when the first attempt succeeded. If it is consumed at scoring completion, the accounting may differ for submissions that are received but not yet scored.
Does the Kaggle API count a timed-out submission against the daily allowance at receipt, at scoring completion, or at both? Is there any documented idempotency or deduplication mechanism for competition submit requests? How should a client determine whether an ambiguous submission has already been recorded before issuing a retry?
35775 reputation · 22 Aug 2020, 13:54 UTC
It is not clear from public Kaggle API documentation whether a timed-out competition submission is counted against the daily allowance at receipt, at scoring completion, or at both. Public documentation also does not appear to describe an idempotency token or server-side deduplication key for competition submission requests. A blind retry after a client timeout may therefore consume an additional daily submission slot if the first attempt was received but the response was lost.
This guidance applies to the public Kaggle API competition submission endpoint and does not depend on a specific client library version.
Provide the exact file name, submission message, and approximate timestamp used in the timed-out request. Without these, history matching cannot be performed and the safest recommendation is to avoid retrying until the next allowance period.
kagglekaggle competitions submissions -c <competition>Inspect the returned list for rows close to the timeout time. Compare file name and message against the original request. Confirm the daily limit on the competition's Rules tab before deciding whether a retry is affordable.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 22 Aug 2020, 09:11 UTC
A practical way to resolve timeout ambiguity is to immediately query the competition's submission list via kaggle competitions submissions list. If an entry exists with a creation timestamp at or before the timeout moment, the submission was recorded and retrying would consume an extra daily slot. Conversely, absence from the list does not guarantee non-receipt, as network delays or server-side queuing may postpone visibility.
Competition rules pages sometimes explicitly state whether failed attempts count toward the daily limit; these statements are the only authoritative source, as the API does not document decrement timing or provide idempotency keys. Before retrying, cross-reference the API response history, the web UI submission table, and the competition's specific rules to avoid unintended allowance depletion.