dev/build?flush just overloads the meaning of both dev/build and flush, IMO.

I'm not really intimate with how the schema generation works… but I guess the heavy lifting is to assemble all the fields, right? It wouldn't be possible to assemble the fields, hash them and compare the hash to the previous hash from the cache?

I use ?flush=1 rarely, but I think there are a lot of devs out there that just do dev/build?flush=1 all the time… so these might be unhappy about my suggestions 😉

Option D - speed up cache build, then do Option C heh. Not sure how realistic that is though

I think it would be tolarable to add it when also flushing

Yeah the problem is that we can’t 100% determine when a flush is needed (technically it’s when you change a single line of PHP or YAML), so I think we’ve got three options: Option A: Force devs to explicitly create/flush cache through separate endpoint Option B: Create an imperfect cache invalidation check in dev/build which works about 95% of the time, but doesn’t work if you define types and fields through PHP rather than YAML. It means any change to YAML (regardless if it’s related to GraphQL) could add ~30s to your dev/build. Rely on devs to remember the edge cases when they need to flush explicitly Option C: Always invalidate GraphQL caches in dev/build, which will add ~30s to your dev/build every time

Those ~30s figures are relative to the size of your schema, but in the end every DataObject managed through the CMS needs a GraphQL type in order to work in an API-driven CMS UI, even if you’re not using GraphQL for your own application.

If the system can automatically detect changes that would require a cache rebuild, then it could also happen upon dev/build imho. But the +60 Seconds of build-time will raise a plethora of other issues… mainly ones around php execution time

I think the schema cache should be rebuilt upon dev/build?flush=1, since only flushing should rebuild caches. Or that's my experience with the silverstripe caching systems at least