HBI is reporting an issue for their List endpoint that uses Kessel bulk checks, where due to a staleness configuration in Kessel (Spicedb), there is a small chance that customers who do the following

• Register a host
• Call the List endpoint to view the host

will see inconsistent results from a bulk access check (like the List endpoint in HBI).

Summary of options from rhit-ahenning 

First, I would NOT expose the consistency token in the API to clients. If we use the consistency token (what we affectionately abbreviate "ktns" pronounced "kittens" ), it would be something internally to HBI or internally to Kessel.

I lay this line in the sand because it is too great a degree of coupling to implementation detail that ripples through the architecture of systems.

That said, there are 4 options we have I think:

1. Do nothing. We would do this if we think we are already sitting at the right trade off b/w UX and DX & operational complexity.
2. HBI starts utilizing ktns internally – trade DX for UX
3. Kessel inventory handles using the ktns internally on HBI's behalf – mostly an internal trade within different aspects of UX & operations.
4. We turn off the "staleness" setting – another internal trade between different aspects of UX & operations.

Acceptance Criteria

• Understand and document the impact of this issue 
• Discuss tradeoffs and decide if this is a risk that we can accept or if we need to fix it
• Implement fix.