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
Users need to configure specific URL paths that are used by the source-http-ingest connector. The current UX for that is pretty confusing, and we'd like to make setting the paths more straightforward. Currently, the paths must be specified as part of the endpoint config, which gets collapsed in the UI after the first successful discover as part of capture creation. They must then "refresh" to do another discover after changing the paths in the endpoint config. This is particularly confusing because the resource config of each binding presents an editable path field, so users try to change it there and run into confusing errors like endpoint config contains paths [...], which are not represented in the list of bindings.
Originally, the decision to make paths part of the endpoint config was driven by the need to have auto-discovers return the same consistent list of bindings. That's still very much a requirement, which complicates things here.
The current UX is a result of trying to maintain backward compatibility. Of course that's always nice, but in this case it seems warranted to make a breaking change if that's required in order to deliver a significantly improved UX.
The text was updated successfully, but these errors were encountered:
Users need to configure specific URL paths that are used by the source-http-ingest connector. The current UX for that is pretty confusing, and we'd like to make setting the paths more straightforward. Currently, the paths must be specified as part of the endpoint config, which gets collapsed in the UI after the first successful discover as part of capture creation. They must then "refresh" to do another discover after changing the paths in the endpoint config. This is particularly confusing because the resource config of each binding presents an editable
path
field, so users try to change it there and run into confusing errors likeendpoint config contains paths [...], which are not represented in the list of bindings
.Originally, the decision to make paths part of the endpoint config was driven by the need to have auto-discovers return the same consistent list of bindings. That's still very much a requirement, which complicates things here.
The current UX is a result of trying to maintain backward compatibility. Of course that's always nice, but in this case it seems warranted to make a breaking change if that's required in order to deliver a significantly improved UX.
The text was updated successfully, but these errors were encountered: