Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: Documenting known issues and discrepancies #29860

Closed
ronag opened this issue Oct 6, 2019 · 1 comment
Closed

doc: Documenting known issues and discrepancies #29860

ronag opened this issue Oct 6, 2019 · 1 comment

Comments

@ronag
Copy link
Member

ronag commented Oct 6, 2019

We have a few strange behaviours that we won't fix or have not yet fixed due to time limitations or compatibility concerns.

A common one is e.g. the callback parameter to different stream methods that have discrepancies such as:

  • callback is not always invoked.
  • callback does not always error when we might actually expect it to.
  • callback does not always error with the error we might actually expect it to.
  • callback with error does not always emit 'error'.
  • callback is not always invoked asynchronously.

Should we add descriptions for these edge cases possibly inside some kind of markdown block with a comment about when these are relevant, might be fixed in the future and recommendations on how to workaround them while at the same remaining as compatible as possible with future fixes. Including a "doc backport" into previous versions. This would possibly also help with migrating the ecosystem away from assumptions based on these discrepancies.

My main concern with this is that users might start depending on these "incorrect" behaviours which might make them even more difficult to fix, i.e. the exact opposite of the original intention.

I do appreciate that this adds additional maintenance, but maybe we can be explicit about that these comments are not complete and added on best effort basis.

Some of these issue are of course documented indirectly in our issue tracker but I'm I don't think most users will actually look and find the relevant issues in the tracker.

@ronag
Copy link
Member Author

ronag commented Oct 6, 2019

Having written this down it occurs to me that this is a very nice to have in theory but probably unmanageable in practice.

@ronag ronag closed this as completed Oct 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant