Sylvain Lebresne

> because I'm pretty sure my use case falls into that example (i.e. multiple subgraphs share the enum for types, only one uses it for input). Sounds like it. Essentially,...

Created https://github.com/apollographql/federation/issues/2006 for following up on a more flexible rule. Fair warning that I'm about to leave on vacation for a few weeks so won't personally follow up more on...

Closing this since the docs have been updated and we have #2006 to follow up on some improvements, and so I don't ther is anything to be done here (but...

Unfortunately, this kind of limitations is a consequence to how the type ownership model of fed1 works, and given the current fed1 code, it's really hard to lift that kind...

Apologies for the long delay following up on this. I've just pushed #2120 to allow using fields with arguments in `@requires` in general. This had been disabled initially because I...

> Note that the above only works for older versions of apollo-server Out of curiosity, how do you apply your custom directive logic on the schema in general (that is,...

> it stumbles over any `extend type ...` declarations where the type is in another subgraph. Hum, forgot about that, my bad. I believe (haven't tested, sorry) you could work-around...

Fwiw, doing this is not imo worth the potential trouble, as least not as a standalone change. In principle, I don't disagree that using the enum would be a bit...

There is kind of 2 problems here: 1. the first one is the same one that I described on #1866 and should be fixed in a similar way (unsurprisingly so,...

Pushed fixes for both problems as #1874. Always a bit less confident about the fed 1 codebase, but this seem to work.