Jeremy Lempereur

It looks to me like the reason why #412 had been postponed is that the next batch of changes would happen [when GATs stabilize](https://github.com/tower-rs/tower/issues/412#issuecomment-584455030). Given it doesn't seem to be...

Hi! Thank you for submitting this issue, and especially for providing us with very clear instructions on how to reproduce the behavior! The query that is sent is effectively part...

Not sure if it belongs in here, but error handling in native plugins is [pretty cumbersome as well](https://github.com/apollographql/router/issues/1403#issuecomment-1192862415). Is there an issue tracking this specifically?

Marked as blocked while waiting for a sandbox update, this should upgrade automatically on the routers side (as soon as the cdn gets the update)

It imo is even less important given the fact we d like to separate the http and the gql parts of the lifecycle even further.

This might be a right opportunity to talk about the merge policy (who gets to merge? how many approvals are required?) as this is something @bnjjj asked me and we...

I poked around at the error structure in js land, and theres some information we're not retrieving, which may sometimes contain things such as "path" and "relative offset" of errors...

It seems like 10s is the [default timeout](https://docs.docker.com/compose/reference/stop/) for docker-compose stop. Moreover the router is currently waiting for a [Ctrl+C](https://github.com/apollographql/router/blob/9c0281eb82c74313ede6534538e29c247c96c6b2/apollo-router/src/main.rs#L172) shutdown signal, which is probably not what docker sends. I'll...

Quoting [docker documentation](https://docs.docker.com/compose/faq/#why-do-my-services-take-10-seconds-to-recreate-or-stop): Compose stop attempts to stop a container by sending a SIGTERM. It then waits for a default timeout of 10 seconds. After the timeout, a SIGKILL is...

Thanks for reopening it, I’ll check next week