WhatBrokeToday
Today's Trends
mediumInvestigatingKubernetes

Kubernetes List Requests with Limit and Field Selector Return Latest Revision Instead of Exact ResourceVersion

  1. Investigating(current)
  2. Trending(upcoming)
  3. Workaround available(upcoming)
  4. Resolved(upcoming)

Executive summary

List requests with a limit and resourceVersion, without resourceVersionMatch, are incorrectly served at the latest revision rather than the requested exact revision when the field selector targets a single object. This affects API queries for single objects like ConfigMaps by name, returning current data and the wrong resourceVersion.

No verified workaround yet

None of the linked reports describe a mitigation. Follow this incident to hear when one appears.

Official fix
Technical root cause

Under active investigation. No report has identified a root cause yet.

Evidence

1 report · 1 GitHubShow
  1. [1]
    GitHub First report
    List with `limit` and `resourceVersion` (no `resourceVersionMatch`) is served at the latest revision, not the exact one, when the field selector names one object(opens GitHub issue in a new tab)

    What happened? A list request with limit=<n> and resourceVersion=<rv>, rv not 0, and no resourceVersionMatch is served at <rv>, except when the field selector names a single object: GET /api/v1/namespaces/<ns>/configmaps?fieldSelector=metadata.name=<name>&... GET /api/v1/configmaps?fieldSelector=metadata.namespace=<ns>,metadata.name=<name>&... These two return the object as it is now and set the list's metadata.resourceVersion to the current revision. The same request without the name…

    by jiren-the-gray 0upvotes 4comments

Timeline

  1. First report on GitHub issue

    List with `limit` and `resourceVersion` (no `resourceVersionMatch`) is served at the latest revision, not the exact one, when the field selector names one object

    Source