Hi everyone, We are upgrading a couple of projects to Prefect 3 and stumbled upon a couple of related but different issues, so we're reaching out here for ideas on how to address them. The context involves a couple of data analysis projects that must run locally and do not require any fancy scheduling or retrying, let alone production deployment. Admittedly, this is probably not the most common use case for Prefect, but we use it anyway to organize the analysis and, most importantly, to take advantage of caching task results. This way, we only re-run what is not up to date with the latest data. First issue: Nested flows that pass along cached task results do not seem to work well with the local sqlite-based server, leading to this error:

uvicorn.error - Exception in ASGI application
sqlite3.OperationalError: database is locked
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database is locked
[SQL: INSERT INTO flow_run (flow_id, deployment_id, ...

I suspect, it's because "When a nested flow run starts, it creates a new task runner for any tasks it contains.". And although "Nested flow runs block execution of the parent flow run until completion.", it does not seem to release the lock that the parent flow has on the sqlite database and it ends up clashing with the process running the nested flow. (emphasis in that I suspect. I did not investigate prefects' internals, but the error happens reproducibly whenever I try to run a nested flow, running a prefect flow locally with a sqlite-backed flow, even in a minimal reproducible example where no other parts of the code could be making a mess). Two questions: - Am I right in my suspicion?, or could be something else? - Is there a way to avoid this error, while still using the default sqlite-backed local server? (I guess by just using postgres it would solve, but firing-up a postgres server is kind of overkill for our use case) A workaround could be, do not run a nested flow, but rather use a task that calls other tasks, which is also one of the new features of prefect 3.0. That kind of worked, but then I stumbled upon an issue with caching. Second issue: It seems the cache policy TASK_SOURCE does not recursively check for code changes in nested tasks. So, if mytask calls mysubtask, and I use the TASK_SOURCE cache policy across the board, the first run works nicely and caches all task results. If I change the code of mytask, it still works as expected. However, the cache policy fails when I change the code of mysubtask. Apparently, it only checks that the source code of mytask has not changed, loads its cache accordingly, and skips running the task (as expected), but fails to notice that the code of mysubtask has changed. I suspect the answer is no, but, I ask anyway. Is there a way to nudge Prefect to recursively apply the cache policy? (I also suspect the other answer is, for that use case you can use a nested flow, instead of a subtask, but yeah, that's going back to the first issue in our case) Ok, sorry for such a long post and thanks in advance for any ideas.