Implement persistent data cache option and update cache key logic

[conico974]

Introduce a new option to maintain the data cache across deployments and adjust cache key generation to reflect this change. Fix issues related to tag caching and ensure proper handling of cache keys in various scenarios.

BREAKING CHANGE: Incremental cache keys are now an object of type CacheKey instead of a string. The new type includes properties like baseKey, buildId, and cacheType. Build_id is automatically provided according to the cache type and the dangerous.persistentDataCache option. Up to the Incremental Cache implementation to use it as they see fit.

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: e036b6816cc3633ef5b12573e91f9811e8ddddc3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@opennextjs/aws	Minor
app-pages-router	Patch
app-router	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vicb]

Is the fix related to the other changes? (Maybe clarify in the PR description)

There are conflicts.

I'll take a look later today

[conico974]

My bad i rebased on the wrong branch... I'll fix it

[pkg-pr-new[bot]]

Open in StackBlitz

pnpm add https://pkg.pr.new/@opennextjs/aws@920

commit: e036b68

[conico974]

I'll update the PR with the changes later today

[vicb]

Thought: In the Couldflare adapter the cache key is prefix/build-id/hash(key)

• build-id is used to partition the cache
• we need to hash(...) to fit within the allowed length and chars

That will become harder to do with this PR.

There are multiple ways to solve this but while thinking about this I was wondering if the change could not be implemented by only updating the overrides? i.e. we could pass a key that is independent of the BUILD_ID and then up to the override to add the build Id or not.

[conico974]

There are multiple ways to solve this but while thinking about this I was wondering if the change could not be implemented by only updating the overrides? i.e. we could pass a key that is independent of the BUILD_ID and then up to the override to add the build Id or not.

That's exactly what was done before (except for the composable cache). I feel like this is something that we need to handle here, not the override itself. It feels weird to have to do the same thing on every single override.

One option would be to have a special type as a key like

interface CacheKey {
  baseKey: string,
  buildId?:string
}

You can then decide what you do with it.

[vicb]

One option would be to have a special type as a key like

+1

It could also help alleviate the confusion between key: string and baseKey: string