Feature Request: Option to always record tape for incoming reqeuest

[thejettdurham]

Hello!

I discovered Talkback yesterday and really dig the simplicity of its API and that the tape format is easily human readable. I'm working on adding new testing infrastructure to an existing large system, and see this as a valuable tool to transparently sit between components and record activity between them for later analysis and playback (via another tool, as I don't think Talkback supports arbitrary tape replay right now)

However, Talkback's behavior of replaying tapes matching an incoming request subverts this use-case. Consider the following hypothetical request sequence:

• GET /comment: Get all comments
• POST /comment: Create a new comment
• GET /foo: Get all comments again, this time with the newly created one

In this use-case, we expect the second GET call to return a different response from the first, but Talkback will only record the first GET request in this sequence and replay it for the second. This is problematic when situating Talkback as a transparent middle-man between two existing system components.

So, I propose an option that allows the "always replay" behavior to be disabled, and thereby enabling this use-case.

Also, I admit that it's entirely possible that there exists a better tool for this use-case and that it doesn't make sense to include this behavior in Talkback. I'm definitely open to alternatives, but my searching around the ecosystem kept leading me back here. If anyone knows of such a better tool, please let me know! :grin:

[tartale]

I have a need for this feature as well, albeit with a caveat - for each request, I'd like to be able to provide a function that can examine the request, and decide to either:

• cache the request (i.e. record a tape, and use it later)
• not cache the request (i.e. record a tape, and don't use it later)
• pass-through the request (don't record a tape at all)

My use case is similar; talkback is sitting transparently between components and recording activity, but I'm using this for test isolation. In other words, some requests should go through to the component under test, and the others should be cached, or simply recorded.

What do you think?

[thejettdurham]

Personally, I like the idea! So instead of having an option like cache: boolean, it would be shouldCache: Request => boolean, right? Would the predicate need anything else passed to it?

[tartale]

I was thinking it would be something like cacheMode: Request => enum, where enum is something like 'cache' || 'no-cache' || 'pass-through', since there's potentially three distinct behaviors?

[thejettdurham]

Oh I see...I didn't read your use-cases clearly enough 😅 Yeah, so your signature looks right then 3 possible options.

I have a PR open for my use case right now, I'll see later on today if it can be adapted to the more general case as well.

[thejettdurham]

Okay, sorry for the delay, but I got my PR updated to take a cacheMode option that provides the desired behavior. Now we play the waiting game, it seems :smile:

[ijpiantanida]

@thejettdurham @tartale I took some time to reply because I wasn't sure how to approach this problem. I ended implementing the different modes but through the record option instead of introducing a new one. You can read more here. Feedback welcome 😃

@tartale for your pass-through case, you'd have to set record: RecordMode.DISABLED and fallbackMode: FallbackMode.PROXY.

I just released v1.10.0 which includes this feature. Thanks for using talkback and for the useful idea.

[tartale]

@ijpiantanida cool, thanks! I updated, will try this out