#Mystery solved? Module loading cache invalidation

1 messages · Page 1 of 1 (latest)

glacial sand
#

🧵

royal yoke
#

👀

#

pre- or post- theseus?

glacial sand
#

orthogonal

#

<@&946480760016207902>

#

I noticed it because now we commit our generated bindings. So when we get churn in the generated bindings, they show up in the diff.

#

And one thing I noticed:

  • Module A imports module B
  • Module B makes a tiny implementation change, that DOES NOT CHANGE ITS API. For example it adds a single line comment.
  • As a result, line information of all its functions are shifted.
  • As a result, source map injected in A's client bindings are changed
  • As a result, the source directory of A's module has changed
  • As a result, loading A is invalidated
torn topaz
glacial sand
#

We see it in the git diff. But meanwhile, it's happening at module load, independently of what's in git or not.

#

TLDR: sourcemap injection into client bindings is causing a LOT of module loading invalidation (my theory)

torn topaz
#

We could revert source map for now as a quick n easy fix

royal yoke
#

Hm that makes sense but I'm also not sure if we ever had the desired the behavior here, regardless of sourcemap. I guess the desired behavior here would be something like:

  1. When it comes to codegen cache: if Module A depends on Module B, then a source code change to Module B should not invalidate codegen for Module A (since Module B's types can't be exposed anyways)
  2. When it comes to function call cache: if Module A depends on Module B, then a source code change to Module B should result in function call cache to Module A being invalidated (since even if API doesn't change the implementation could have changed)
    • It would be cool to be more fine grain here but trying to distinguish what cache to bust based on a given source code line change is a very hard problem

I don't know if pre or post theseus we ever actually followed that exactly. We probably should though. Much easier post theseus

glacial sand
#

So, yes

#

Also, I guess once codegen is fully decoupled from load (which is imminent thanks to Yves' work) then this particular problem will go away at runtime: we will see churn in git, but the same churn will no longer invalidate module loading

EDIT -> mmm I guess it will, if we commit the churn 🙂

So correction: at least we can deal with the codegen churn at the codegen level, which makes it less mysterious and easy to spot & debug

royal yoke
#

Yeah, today we already have different cache keys for different module-related operations since there's some that are highly client specific (i.e. what is the exact path of the module as loaded from the client's local filesystem) and others that are not client specific (codegen+function call).

But I guess we need an extra split so it's separated between:

  1. client specific operations
  2. codegen
  3. function call

Think it should be mostly a matter of repeating the pattern we already follow to scope cache, just adding another branch now