Skip to content

bug(core): km_core_state_context_set_if_needed needs more nuance for when to update cache 🌱 #10100

@mcdurdin

Description

@mcdurdin

Now I am having worries about the algorithm here. There are multiple scenarios, and just want to make sure that I am covering them all.

Ignoring markers..., these are the scenarios I can see:

  1. cached context identical to app context
  2. cached context same length as app context but content is different
  3. cached context is shorter than app context, but content is same as far as it goes
  4. cached context is shorter than app context, but content is different
  5. cached context is longer than app context, but content is same as far as it goes
  6. cached context is longer than app context, but content is different.

I think those are the only 6 scenarios. What do we want to do for each one?

  1. unchanged
  2. changed, set cache to app context
  3. lengthen to app context, but keep markers, consider unchanged?
  4. changed, set cache to app context
  5. shorten to app context, but keep markers, consider unchanged? or changed + set to app context?
  6. changed, set cache to app context

We have to consider the rolling buffer that we'll have as we add new content, and that will impact whether or not the app context is longer than cache (remembering that the cached context may have markers which will shorten the overall non-marker content of it).

So number 3 and number 5 6 need careful consideration.

Relates to #10098.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions