EnqueueLinks modifies userData when adding label, causing unexpected behavior

[mvolfik]

Imagine the following code in a page handler function

const data = { title: $('title').text() };

await enqueueLinks({
    selector: '.WebFooter-bottomLinks a',
    userData: data,
    label: 'footer-link',
});

await enqueueLinks({
    selector: '.LandingPage-actorListCards > a',
    userData: data,
    label: 'actor-link',
});

Then all requests are enqueued with label: 'footer-link', which is quite unexpected. That is due to this code:

crawlee/packages/core/src/enqueue_links/shared.ts

Lines 202 to 203 in 6781f12

	requestOptions.userData ??= options.userData ?? {};
	requestOptions.userData!.label ??= options.label;

enqueueLinks modifies the userData object, and adds the label only if it's not present already. A simple workaround in user code is to provide a shallow copy of the data object (userData: { ...data }).

The possible resolutions are two:

• do the shallow copy inside the enqueueLinks code (possibly only when setting the label)
• always override the label if provided, even if it already is present in the userData (so enqueueLinks({ userData: {label: 'foo'}, label: 'bar'}) would enqueue requests with the label bar).

I'm not really sure which variant is better

---

Full reproduction repository: mvolfik/apify-enqueuelinks-bug

cc @tomasjindra - that's the issue we debugged together

[B4nan]

I'd vote for always overriding the label, that would be the expected behavior to me.

[corford]

Personally, I wouldn't expect a label from my first call of enqueueLinks() to appear on userData from a second call to enqueueLinks() (if for, that second call, I hadn't explicitly passed a label).

Or said another way, I wouldn't expect enqueueLinks() to mutate a passed userData object - shallow copy feels more obvious to me (if you want a 'label' prop to persist on the passed userData object, then explicitly set it yourself rather than indirectly via a separate param to enqueueLinks() ).

[B4nan]

Well, Request.label is a shortcut for working with Request.userData, it is supposed to mutate it, and if you ask me, it is also supposed to take precedence.

[corford]

That's fair. We don't use the Request.label shortcut (preferring to be explicit with what we do on userData, since we use it for a lot of our own internal stuff too), so I guess it's from that PoV that, to me, the label param to enqueueLinks felt more internal to that func (and unexpected that it would mutate the passed userData).

[mvolfik]

Well, we can do both - first create a shallow copy, and then override userData.label with label

@B4nan should I do a PR with that?

[B4nan]

Yeah, sure, PR welcome.