adding minutes from 2018-01-24 meeting

[mike-kaufman]

No description provided.

[mike-kaufman]

@watson, @ofrobots - do you either of you have the link from that example code where there was a lazily executed promise that was causing confusion in context propagation?

[ofrobots]

The example I had in mind is a pattern I am starting to see quite frequently with a lazily initialized promise being used as a cache of some async data.

const app = express();

let authTokenPromise;
app.get('/', (req, res) => {
  if (!authTokenPromise) {
     // lazily acquire an auth token.
     authTokenPromise = fetch('some url');
  }

  authTokenPromise.then(() => {
    // business logic.
    // What is my context here?
  });
});

The way continuation-local-storage works today is that it restores the context from the promise into the then callback. The promise was created in the first incoming request which means that the business logic will always run in the context of the first incoming request rather than the context of the current request (what the programmer intended).

The other link that might be interesting is this: othiym23/node-continuation-local-storage#114. That was a special case of the general problem above.

There is some more discussion on this topic here: othiym23/node-continuation-local-storage#64

[Qard]

I've also seen promises passed around with callbacks attached in a multi-consumer style, which makes the graph confusing because everything points to the creation point of the promise, not the insertion point of the callback.

[mike-kaufman]

I've also seen promises passed around with callbacks attached in a multi-consumer style,

@Qard - can you post some short example code? I'm trying to work on visualizations of the graphs produced by different coding patterns to help everyone get on same page.

[Qard]

A good example I've seen is people replacing the delayed routing body-parser approach typical in express with a stored promise, for better performance.

app.use((req, res, next) => {
  req.body = parse(req) // returns a promise of the result of the consumed stream
  next()
})

Once that middleware is run, the req.body promise can now be used anywhere, but that use will point back to the middleware rather than where the use actually occurs.

[mike-kaufman]

@ofrobots - check out example code & visualization here: https://mike-kaufman.github.io/async-context-definition/examples/lazilyInitializedPromise/slideShow/async-context.html. Given our model & graph shown there, you should maintain correct context. Feel free to open an issue in https://github.com/mike-kaufman/async-context-definition/issues if you think anything is missing and/or incorrect.

[ofrobots]

@mike-kaufman that model doesn't match my intuition. It also doesn't match all the potential mental models developers can have, as listed in othiym23/node-continuation-local-storage#64.

My intuition is that Execute 16 is linked by Execute 13, it is caused by Link 9. Or, colloquially, the causal parent of the then callback in the second request should be the lazyPromise.

(Let's extract this into a separate issue -> #143)

[mike-kaufman]

@Qard - visualization of your example ishere. Sorry for delay, had this on my machine & then was out of town. Please let me know if you have any questions.

Note that your example highlights an issue, which is where are the logical continuation points and how are those indicated to the user? This example is currently inconsistent with the simpleExpress example. I'll need to rectify these.