Difference between `worker_ctx.context_data` and `worker_ctx.data`

Hi all

I see a lot of examples throughout the nameko source using *context_data*,
e.g. https://github.com/nameko/nameko/blob/286d141af2e0fe3fc5b592228c4cea93ca495d81/docs/examples/auth.py#L41

And a lot fewer examples using *data*
like https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/contextdata.py#L12

I have two questions for you based on these.

1) What is the difference here between these two patterns?

2) If I'm making an RPC call from service A to service B, what is the
correct way to add extra context data to the call so B can access them?

Thanks, as always.

Simon

Looking at this example it's clear how to do this with the standalone
tools: https://gist.github.com/mattbennett/8a67956ea78d4481d5ea9072e770ba4b.
Although it's still not clear why both *data* and *context_data* exist.

What about when using the *RpcProxy*? How can we add context data in this
use-case?

Thanks

···

On Wednesday, 1 November 2017 16:24:03 UTC, simon harrison wrote:

Hi all

I see a lot of examples throughout the nameko source using *context_data*,
e.g.
https://github.com/nameko/nameko/blob/286d141af2e0fe3fc5b592228c4cea93ca495d81/docs/examples/auth.py#L41

And a lot fewer examples using *data* like
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/contextdata.py#L12

I have two questions for you based on these.

1) What is the difference here between these two patterns?

2) If I'm making an RPC call from service A to service B, what is the
correct way to add extra context data to the call so B can access them?

Thanks, as always.

Simon

From the implementation it looks like the only difference is
`call_id_stack` (context_data is a copy of data with that added). this can
probably be cleaned up

as for adding context data, this is typically done by extensions (depends
on where the data is coming from). at ofs we also had a contextmanager
(injected as an extension) that added stuff to the worker context data

anything in there gets propagated automatically by rpc calls and events

d

···

On Thursday, 2 November 2017 08:50:43 UTC, simon harrison wrote:

Looking at this example it's clear how to do this with the standalone
tools:
https://gist.github.com/mattbennett/8a67956ea78d4481d5ea9072e770ba4b.
Although it's still not clear why both *data* and *context_data* exist.

What about when using the *RpcProxy*? How can we add context data in this
use-case?

Thanks

On Wednesday, 1 November 2017 16:24:03 UTC, simon harrison wrote:

Hi all

I see a lot of examples throughout the nameko source using
*context_data*, e.g.
https://github.com/nameko/nameko/blob/286d141af2e0fe3fc5b592228c4cea93ca495d81/docs/examples/auth.py#L41

And a lot fewer examples using *data* like
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/contextdata.py#L12

I have two questions for you based on these.

1) What is the difference here between these two patterns?

2) If I'm making an RPC call from service A to service B, what is the
correct way to add extra context data to the call so B can access them?

Thanks, as always.

Simon

Cool, thanks David.

Having looked over the source i can now see the behaviour. the
entrypoint_hook actually spawns a container with the context data, while
DependencyProviders work with the global WorkerContext instance which only
other Extensions can update.

We've already gone down the route you suggest

Ta

···

On Thursday, 2 November 2017 10:27:32 UTC, David Szotten wrote:

From the implementation it looks like the only difference is
`call_id_stack` (context_data is a copy of data with that added). this can
probably be cleaned up

as for adding context data, this is typically done by extensions (depends
on where the data is coming from). at ofs we also had a contextmanager
(injected as an extension) that added stuff to the worker context data

anything in there gets propagated automatically by rpc calls and events

d

On Thursday, 2 November 2017 08:50:43 UTC, simon harrison wrote:

Looking at this example it's clear how to do this with the standalone
tools:
https://gist.github.com/mattbennett/8a67956ea78d4481d5ea9072e770ba4b.
Although it's still not clear why both *data* and *context_data* exist.

What about when using the *RpcProxy*? How can we add context data in this
use-case?

Thanks

On Wednesday, 1 November 2017 16:24:03 UTC, simon harrison wrote:

Hi all

I see a lot of examples throughout the nameko source using
*context_data*, e.g.
https://github.com/nameko/nameko/blob/286d141af2e0fe3fc5b592228c4cea93ca495d81/docs/examples/auth.py#L41

And a lot fewer examples using *data* like
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/contextdata.py#L12

I have two questions for you based on these.

1) What is the difference here between these two patterns?

2) If I'm making an RPC call from service A to service B, what is the
correct way to add extra context data to the call so B can access them?

Thanks, as always.

Simon

Yeah, it's not very clear. WorkerContext.data is for arbitrary data that
you can stash in the worker context. WorkerContext.context_data is that
same data augmented with the stuff that Nameko adds itself (currently just
the call stack). Could definitely be cleaned up and documented properly!

···

On Thursday, November 2, 2017 at 10:27:32 AM UTC, David Szotten wrote:

From the implementation it looks like the only difference is
`call_id_stack` (context_data is a copy of data with that added). this can
probably be cleaned up

as for adding context data, this is typically done by extensions (depends
on where the data is coming from). at ofs we also had a contextmanager
(injected as an extension) that added stuff to the worker context data

anything in there gets propagated automatically by rpc calls and events

d

On Thursday, 2 November 2017 08:50:43 UTC, simon harrison wrote:

Looking at this example it's clear how to do this with the standalone
tools:
https://gist.github.com/mattbennett/8a67956ea78d4481d5ea9072e770ba4b.
Although it's still not clear why both *data* and *context_data* exist.

What about when using the *RpcProxy*? How can we add context data in this
use-case?

Thanks

On Wednesday, 1 November 2017 16:24:03 UTC, simon harrison wrote:

Hi all

I see a lot of examples throughout the nameko source using
*context_data*, e.g.
https://github.com/nameko/nameko/blob/286d141af2e0fe3fc5b592228c4cea93ca495d81/docs/examples/auth.py#L41

And a lot fewer examples using *data* like
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/contextdata.py#L12

I have two questions for you based on these.

1) What is the difference here between these two patterns?

2) If I'm making an RPC call from service A to service B, what is the
correct way to add extra context data to the call so B can access them?

Thanks, as always.

Simon

could you describe your use-case anyway please? interested in examples of
this

d

···

On Thursday, 2 November 2017 10:41:01 UTC, simon harrison wrote:

Cool, thanks David.

Having looked over the source i can now see the behaviour. the
entrypoint_hook actually spawns a container with the context data, while
DependencyProviders work with the global WorkerContext instance which only
other Extensions can update.

We've already gone down the route you suggest

Ta

On Thursday, 2 November 2017 10:27:32 UTC, David Szotten wrote:

From the implementation it looks like the only difference is
`call_id_stack` (context_data is a copy of data with that added). this can
probably be cleaned up

as for adding context data, this is typically done by extensions (depends
on where the data is coming from). at ofs we also had a contextmanager
(injected as an extension) that added stuff to the worker context data

anything in there gets propagated automatically by rpc calls and events

d

On Thursday, 2 November 2017 08:50:43 UTC, simon harrison wrote:

Looking at this example it's clear how to do this with the standalone
tools:
https://gist.github.com/mattbennett/8a67956ea78d4481d5ea9072e770ba4b.
Although it's still not clear why both *data* and *context_data* exist.

What about when using the *RpcProxy*? How can we add context data in
this use-case?

Thanks

On Wednesday, 1 November 2017 16:24:03 UTC, simon harrison wrote:

Hi all

I see a lot of examples throughout the nameko source using
*context_data*, e.g.
https://github.com/nameko/nameko/blob/286d141af2e0fe3fc5b592228c4cea93ca495d81/docs/examples/auth.py#L41

And a lot fewer examples using *data* like
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/contextdata.py#L12

I have two questions for you based on these.

1) What is the difference here between these two patterns?

2) If I'm making an RPC call from service A to service B, what is the
correct way to add extra context data to the call so B can access them?

Thanks, as always.

Simon

Hiya

We've a mixture of HTTP and RPC calls between nameko services, plus some
Flask services in the mix there too, and we want to propagate things like a
global request ID and lang between them. Nothing too out of the ordinary.

Thanks again.

···

On Thursday, 2 November 2017 11:15:25 UTC, David Szotten wrote:

could you describe your use-case anyway please? interested in examples of
this

d

On Thursday, 2 November 2017 10:41:01 UTC, simon harrison wrote:

Cool, thanks David.

Having looked over the source i can now see the behaviour. the
entrypoint_hook actually spawns a container with the context data, while
DependencyProviders work with the global WorkerContext instance which only
other Extensions can update.

We've already gone down the route you suggest

Ta

On Thursday, 2 November 2017 10:27:32 UTC, David Szotten wrote:

From the implementation it looks like the only difference is
`call_id_stack` (context_data is a copy of data with that added). this can
probably be cleaned up

as for adding context data, this is typically done by extensions
(depends on where the data is coming from). at ofs we also had a
contextmanager (injected as an extension) that added stuff to the worker
context data

anything in there gets propagated automatically by rpc calls and events

d

On Thursday, 2 November 2017 08:50:43 UTC, simon harrison wrote:

Looking at this example it's clear how to do this with the standalone
tools:
https://gist.github.com/mattbennett/8a67956ea78d4481d5ea9072e770ba4b.
Although it's still not clear why both *data* and *context_data* exist.

What about when using the *RpcProxy*? How can we add context data in
this use-case?

Thanks

On Wednesday, 1 November 2017 16:24:03 UTC, simon harrison wrote:

Hi all

I see a lot of examples throughout the nameko source using
*context_data*, e.g.
https://github.com/nameko/nameko/blob/286d141af2e0fe3fc5b592228c4cea93ca495d81/docs/examples/auth.py#L41

And a lot fewer examples using *data* like
https://github.com/nameko/nameko/blob/0d8239a1580b1879c872c77dfcdba601040e064f/nameko/contextdata.py#L12

I have two questions for you based on these.

1) What is the difference here between these two patterns?

2) If I'm making an RPC call from service A to service B, what is the
correct way to add extra context data to the call so B can access them?

Thanks, as always.

Simon