Split DagterGraphQLContext into ProcessContext and RequestContext


Split DagterGraphQLContext into ProcessContext and RequestContext

This diff splits the DagsterGraphQLContext into two separate classes:

  • ProcessContext
  • RequestContext

This split is only meaningful in the context of the Dagit webserver. The ProcessContext is long-lived, and the RequestContext is created for every request. The RequestContext stores (1) a reference to all the repository locations on the ProcessContext at the start of the request and (2) a snapshot of the Workspace state at the start of the request.

This is needed due to the introduction of the repository location watch threads that can modify the global context. The problem was that if a request was accessing a repository location at the same time the watch thread was cleaning it up, bad things would obviously happen.

Instead, the watch threads only run on the ProcessContext and are free to reload the repository locations and workspace as they like. RepositoryLocationHandles are not immediately cleaned up on location reload, and instead are cleaned up whenever all references to them in both the ProcessContext and all RequestContexts are gone.

This diff also brings back the sqlite_instance_deployed_grpc_env test suite.

Resolves https://github.com/dagster-io/dagster/issues/3404

Test Plan: unit

Reviewers: alangenfeld

Reviewed By: alangenfeld

Differential Revision: https://dagster.phacility.com/D5953