Skip to main content

Validation and troubleshooting

Validate network connectivity, protocol conformance and business results separately.

Validate network connectivity, protocol conformance and business results separately. Record the endpoint name and path, request ID, HTTP status, organization and date for each test. Do not log complete tokens or original user content.

Eight-endpoint acceptance checklist

EndpointSuccessful casesRequired boundary cases
Get latest statistics dateComplete data date and ds=nullDo not publish incomplete dates
Query organization usage overviewFive periods, organization totals and daily trendsPreserve null balances; detect incorrect organizations, dates and totals
Query member usage listAll pages, sorting, filtering and actual bound usersMore than 200 members, empty results, tied sort values, duplicates and omissions
Query member daily usage trendConsecutive daily values for the current userdays=1/30, encoded user IDs and expired dates
Query quota rules and periodCurrent period, minimum and maximum limitsPeriod boundaries and unknown upper limits; preserve the product minimum of 500
Query member quotasApplied, unconfigured and not-found statesResponse order and count, null values and the actual applied revision
Set member limitA 500-credit limit for one user with a complete acknowledgementDuplicate requests, retry after a lost response and mismatched acknowledgement fields; do not add to the limit or reset usage
Query organization quotaReal-time organization total and usageUsage exceeding the total, organization mismatch and an error for unknown quotas
Common behaviorValid credentials, organization and JSON401/403, invalid parameters, timeout, non-JSON content, oversized responses and redirects
End-to-end acceptance must also verify that model calls use the same external identity, the enterprise model enforces limits, statistics refresh publishes a new date, and pages, exports and member trends match enterprise data. Fixed examples from a mock provider do not prove actual metering or quota enforcement.

Error handling

Return a non-200 HTTP status and JSON on failure. Do not hide business failures in error fields inside an HTTP 200 response.
HTTPExample codeWhat to check
400 / 422invalid_argument / unsupported_periodParameters, field types and period; correct the request first
401 / 403unauthenticated / forbiddenToken and organization authorization; do not hide failures with empty data
404member_not_found / snapshot_not_foundWhether the member or historical data exists and the endpoint is implemented
409snapshot_not_readyWhether the complete data is ready; QwenWork retains the previous snapshot
429rate_limitedRate-limit budget; Retry-After may be returned
500 / 502 / 503 / 504upstream_unavailableEnterprise dependencies, network and timeouts; recover within the host's existing retry budget
retryable and Retry-After do not guarantee an immediate SDK retry. Background refresh and quota dispatch manage retries separately. Client pages receive errors mapped by the QwenWork service, which may differ from the original enterprise service code. Correlate service logs using the request ID.

Diagnose by symptom

SymptomCheck firstInterpretation
Local curl succeeds but the console connectivity check failsDNS, ports, certificates, routes and IP SAN from the Biz networkLocal connectivity does not prove Biz connectivity
Connectivity succeeds but statistics still failLatest-date JSON, all five periods of organization and member usage, all pages and identity bindingsThe check only verifies HTTP 200 from Get latest statistics date; it does not parse the response
Organization quota fails while other endpoints workWhether Query organization quota is implemented and returns string amounts and the correct organizationA 404 from this endpoint does not mean the extension is disabled
HTTP 200 produces a protocol errorA data wrapper, nulls, dates, JSON types and required fieldsHTTP success does not prove contract conformance
Quota appears off by a factor of 10000Quota amounts must be minor-unit strings; statistics must be credit numbers"5000000" in a quota endpoint represents 500 credits
Setting a member limit keeps retryingExact match of user, binding, revision, amount, validity and period in the acknowledgementEchoing desired_revision alone is insufficient
Statistics contain only the first 200 members or the whole batch failspage_no, has_more, total, non-final page length and duplicate IDsRead all pages with stable pagination
Organization and member totals differFive-period boundaries, totals across all pages, cycle_used_credits and period usageUse the same measurement rules for one ds
Switching providers or changing sample data does not update the pageWhether the source date is later than the locally published dateSnapshots for the same date are immutable and are not overwritten
An unknown balance appears as 0Nullable balance or reset date replaced with a defaultUse null for unknown statistics; return an error for an unknown organization quota
Reusing the old token after an address change failsWhether the new service accepts the credential and organization authorization matchesThe console permits reuse but does not guarantee that the new service accepts it

Complete integration test record

A delivery-ready test record should include:
  1. QwenWork installation version, provider version, protocol version and test date.
  2. Results for all eight endpoints, related request IDs and response validation results.
  3. Test organization and user bindings, period boundaries, unit conversions and retry cases.
  4. Source ds and published QwenWork ds, with organization and member totals reconciled.
  5. Actual model consumption and quota enforcement results from the enterprise model.
Run tests involving writes in a separate test organization. After confirming the protocol, enable the production organization through the agreed delivery process.
Validation and troubleshooting - QwenWork