Problem/Motivation

@paul121 discovered this in https://www.drupal.org/project/farm/issues/3241078#comment-14260404

This has led me to discover another more general bug re: caching... logs that are "done" with a timestamp in the future add another level of complication here. This is especially important for requests via the API. Consider the following:

  1. Create an asset.
  2. Create a movement log in the future (5 minutes) with the status set as "done".
  3. View the asset's JSONAPI resource (this will cache the asset's resource in the jsonapi_normalization cache bin)
  4. Come back in 5 minutes and load the JSONAPI resource. Unchanged.
  5. Go to the log edit page and re-save it without making changes. JSONAPI resource is updated.

Not sure how important this is. It seems like it *could be* semi-straightforward to support this... Drupal has the concept of cache tags and the cache "max-age". *In theory*, when a planned log is created, we could set the asset's cache max-age to be the timestamp of that log. That way anything cached from the asset (and respecting its max-age) would be rebuilt appropriately. Of course, I'm not sure if we're able to specify an individual asset's cache max age... gotta sign off. This would probably be best to tackle in a separate issue.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None.

API changes

Fix caching bug described above.

Data model changes

None.

Comments

m.stenta created an issue. See original summary.

m.stenta’s picture

Priority: Normal » Minor

I think we can lower the priority of this, because in practice a log with a timestamp in the future typically won't be marked as "done". So this is a bit of an edge case, I think.

m.stenta’s picture

Version: 2.x-dev » 3.x-dev
m.stenta’s picture

Version: 3.x-dev » 4.x-dev