Automatically re-execute chained requests #140

Sometimes you want to re-execute a chained request (e.g. if an auth token has expired). Insomnia supports 3 triggers for automatic requests:

• No request history
• Expiration (user sets a TTL)
• Always

It could be helpful to add a 4th trigger: if the chaining request fails. E.g if request B is using an auth token from request A, request B gets a 403 error, you could automatically re-request A then B. This is a much more complicated design so I don't want to include it in the first version.

Design

Design for the user-facing side of this could go a few ways:

Option 1 - Turn !request variant into a mapping

Add fields specifically for the request variant of ChainSource. This requires turning the !request variant from a string into a mapping:

chains:
  auth_token1:
    source: !request
      recipe: login
      auto: !no_history
    selector: $.headers["X-Amzn-Trace-Id"]
  auth_token2:
    source: !request
      recipe: login
      auto: !expire 12hr
    selector: $.headers["X-Amzn-Trace-Id"]
  auth_token3:
    source: !request
      recipe: login
      auto: !always
    selector: $.headers["X-Amzn-Trace-Id"]

Pros

• Only exposes expiration fields to the request variant, which is the only one that will use them
• Using an explicit map implies to the user that configuration is available
• Makes it easy to add additional variant-specific configuration in the future

Cons

• Breaking change
• Adds complexity to the base case, where no auto field is defined (you now need a mapping with one field)

Both cons can be mitigated by continuing to support the !request login format, but that would require some ugly serde code and also increases complexity of documentation, so I don't think I would do that.

Option 2 - Add field to entire Chain object

We could add a field auto_request to Chain for defining auto-request behavior. This field would do nothing on other variants:

chains:
  auth_token1:
    source: !request login
    auto_request: !no_history
    selector: $.headers["X-Amzn-Trace-Id"]
  auth_token2:
    source: !request login
    auto_request: !expire 12hr
    selector: $.headers["X-Amzn-Trace-Id"]
  auth_token3:
    source: !request login
    auto_request: !always
    selector: $.headers["X-Amzn-Trace-Id"]

Pros

• Non-breaking change
• Keeps base case (no auto request) simple and intact
• Simpler to implement and document

Cons

• Allows for meaningless configuration, where the auto_request field is present on variants that don't use it

Option 3 - Support caching in a more general way

We could introduce caching to all chained source variants. Right now the !request variant uses implicit caching with a manual cache refresh (re-running the chained request), while other variants use no caching at all. This is arguably intuitive (and how Insomnia behaves) but self-inconsistent. We could instead remove caching by default for requests (i.e. the equivalent of auto: !always), then support caching for all variants. Additionally, I think it would make sense to have auto: !no_history be implicitly on, since there would be no way to specify that behavior. That makes sense anyway though, because

chains:
  auth_token1:
    # This implicitly never caches
    source: !request login
    selector: $.headers["X-Amzn-Trace-Id"]
  auth_token2:
    source: !request login
    cache: 12hr
    selector: $.headers["X-Amzn-Trace-Id"]
  auth_token3:
    source: !request login
    cache: always
    selector: $.headers["X-Amzn-Trace-Id"]

Pros

• Allows other expensive chained values (e.g. slow shell commands) to be cached
• Easy(-ish) to document
• Improves consistency of behavior
• Non-breaking(-ish) change
  • Existing behavior would change (chained requests would be re-requested always now) but this probably wouldn't "break" anyone's setup, just make it slower

Cons

• Complex implementation
  • We would need a variant-specific caching implementation. Requests are already cached in the requests table and we don't want to duplicate that, so we would need logic to switch between caching mechanisms based on variant
• Default behavior for requests (request is always re-executed) may be unexpected/undesired
  • This can be partially mitigated with good documentation in the user guide