You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For any libraries that define both a custom ResponseClassifier via HttpPipelineBuilder (e.g. like in Storage) and generate protocol methods (e.g. like in Tables), the library-specific ResponseClassifier would be replaced by the generated method-specific classifier.
Today, the only libraries that customize ResponseClassifier are Identity and Storage - neither of which generate protocol methods, so I don't believe any libraries are currently impacted by this.
While it does make sense that the method classifier would take precedence over the library classifier, it would be better if the library-specific classifier was put at the end of the chain using a ChainingClassifier so that the library-specific classifier code can still run for the non-specified status codes.
The text was updated successfully, but these errors were encountered:
For any libraries that define both a custom ResponseClassifier via HttpPipelineBuilder (e.g. like in Storage) and generate protocol methods (e.g. like in Tables), the library-specific ResponseClassifier would be replaced by the generated method-specific classifier.
Today, the only libraries that customize ResponseClassifier are Identity and Storage - neither of which generate protocol methods, so I don't believe any libraries are currently impacted by this.
While it does make sense that the method classifier would take precedence over the library classifier, it would be better if the library-specific classifier was put at the end of the chain using a ChainingClassifier so that the library-specific classifier code can still run for the non-specified status codes.
The text was updated successfully, but these errors were encountered: