David Sutherland
David Sutherland
Not saying it's not doable, it's definitely idealistic... I just think it's not worth our effort right now: - It shouldn't be that common. - We don't even track the...
Yeah, reason I didn't go with separate processes is so the resolvers have access to the central data-store (if it works that way)
Silly idea, and wider scope.. But if cylc-flow `DataStoreMgr` is refactored into `DeltaMgr` and a `DataStoreMgr` (which is imported by the UIS).. This would mean UIS window size(s) are isolated...
The `promise` is gone when I get around to (hopefully soon) upgrading Graphene, and rewriting our own `graphql-ws` (as this uses promises too) .. It appears, `promise` was created by...
The other thing we do is recursively sift through the GraphQL query result (in the middleware) and strip out all the null fields... Not exactly sure how expensive this is.....
Looks fine, tests passing. Probably would need to create this on the `cylc-flow` end to add to subscriptions (which might make more sense, as field(s) in a data-store).
> Would we have to add these fields in cylc-flow or could we shim them into cylc-uiserver similar to how we extend the GraphQL schema? Well, if we add this...
Ah, so it's not about knowing the source of installed/running workflows, it's about knowing `cylc-src` or it's aliases... Yeah, better to keep it at UIS then, and we shouldn't need...
Is this more a UIServer issue, right? i.e. the UIS needs to close the connection after logout?
more updates inc..