JustArchiNET/ArchiSteamFarm · error · TimeoutException
response is null!
Error message
response is null!
What it means
After the GetMyInventoryAsync retry loop exits, ASF asserts the response object is non-null. Because the loop continues on retryable errors and only assigns response on a service call, exiting the loop with no successful call leaves response null, which ASF converts to a TimeoutException with the message 'response is null!'.
Source
Thrown at ArchiSteamFarm/Steam/Integration/ArchiHandler.cs:269
case EResult.Fail:
case EResult.RemoteCallFailed:
case EResult.ServiceUnavailable:
case EResult.Timeout:
// Expected failures that we should be able to retry
continue;
case EResult.NoMatch:
// Expected failures that we're not going to retry
throw new TimeoutException(Strings.FormatWarningFailedWithError(response.Result));
default:
// Unknown failures, report them and do not retry since we're unsure if we should
ArchiLogger.LogGenericError(Strings.FormatWarningUnknownValuePleaseReport(nameof(response.Result), response.Result));
throw new TimeoutException(Strings.FormatWarningFailedWithError(response.Result));
}
}
if (response == null) {
throw new TimeoutException(Strings.FormatErrorObjectIsNull(nameof(response)));
}
if (response.Result != EResult.OK) {
throw new TimeoutException(Strings.FormatWarningFailedWithError(response.Result));
}
if ((response.Body.total_inventory_count == 0) || (response.Body.assets.Count == 0)) {
// Empty inventory
yield break;
}
if (response.Body.descriptions.Count == 0) {
throw new InvalidOperationException(nameof(response.Body.descriptions));
}
if (response.Body.total_inventory_count > Array.MaxLength) {
throw new InvalidOperationException(nameof(response.Body.total_inventory_count));
}View on GitHub (pinned to fe57c4129f)
Solutions
- Increase ASF's ConnectionTimeout so the loop has more time/attempts.
- Retry later when Steam GC service health improves.
- Check whether the bot session is healthy (reconnect) before retrying.
- Reduce concurrent inventory requests to lower GC load.
Defensive patterns
Strategy: retry
Validate before calling
// Increase the chance of a usable response within the loop.
byte timeout = ASF.GlobalConfig?.ConnectionTimeout ?? GlobalConfig.DefaultConnectionTimeout;
if (timeout < 60) logger.LogWarning("ConnectionTimeout low; GC inventory may time out"); Try / catch
try { await foreach (var a in handler.GetMyInventoryAsync()) { /* ... */ } }
catch (TimeoutException ex) when (ex.Message.Contains("response is null")) {
await Task.Delay(retryDelay); // retry once after GC recovers
} Prevention
- Raise ConnectionTimeout for slow/unstable GC responses.
- Throttle concurrent inventory requests to avoid GC overload.
- Retry with backoff rather than immediately re-issuing.
When it happens
Trigger: Every iteration of the retry loop hit a retryable error and exhausted MaxTries without ever receiving a usable response, or the GC callback never invoked the handler within the configured connection timeout.
Common situations: Steam GameCoordinator is degraded for an extended period; the connection timeout (ASF ConnectionTimeout) is too short for a slow GC reply; repeated RemoteCallFailed/ServiceUnavailable over all attempts.
Related errors
- Failed due to error: {0}
- Failed due to error: Client.IsConnected
- classid is null!
- last_assetid is null!
- Failed!
AI-assisted analysis of JustArchiNET/ArchiSteamFarm@fe57c4129f (2026-08-13).
Data as JSON: /api/errors/3ddecc820754aca9.
Report an issue: GitHub.