# {{context.link}} generated is too long to be resolved

**URL:** <https://discuss.elastic.co/t/context-link-generated-is-too-long-to-be-resolved/370157>\
**Category:** Kibana\
**Tags:** elastic-stack-alerting\
**Created:** [November 7, 2024, 8:17am UTC](https://discuss.elastic.co/t/context-link-generated-is-too-long-to-be-resolved/370157 "2024-11-07T08:17:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![blindahl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/blindahl/32/118231_2.png) [@blindahl](https://discuss.elastic.co/u/blindahl)\
**Post date:** [November 7, 2024, 8:17am UTC](https://discuss.elastic.co/t/context-link-generated-is-too-long-to-be-resolved/370157/1 "2024-11-07T08:17:50Z")

</div>

When including {{context.link}} in an email to inform about errors in our application logs we get an issue with the value of context.link seem to get too long when adding some filters to filter out specific log posts. The error we get is:

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/d/0/d0a4687ca11b57640a43e3ac1553e08408e883f6.png)

If you click "Show details" you get this error:

```auto
Error: Locator params not specified. Specify "p" search parameter in the URL, which should be JSON serialized object of locator params.
    at https://<hostname>/d4d06bdf0d1d/bundles/plugin/share/1.0.0/share.plugin.js:2:27529
    at redirect_manager_RedirectManager.parseSearchParams (https://<hostname>/d4d06bdf0d1d/bundles/plugin/share/1.0.0/share.plugin.js:2:28010)
    at redirect_manager_RedirectManager.onMount (https://<hostname>/d4d06bdf0d1d/bundles/plugin/share/1.0.0/share.plugin.js:2:25118)
    at Object.mount (https://<hostname>/d4d06bdf0d1d/bundles/plugin/share/1.0.0/share.plugin.js:2:24165)
    at async https://<hostname>/d4d06bdf0d1d/bundles/core/core.entry.js:1:100139

The above error occurred in D:
    at c (https://<hostname>/d4d06bdf0d1d/bundles/kbn-ui-shared-deps-src/kbn-ui-shared-deps-src.js:67:183485)
    ...

```

To me this looks like the lookup from the URL generated by _context.link_ is getting too long so not all information needed for the link is included. It was obvious when we used Kibana/Elastic v7 since the explicit URL was included in the mail we sent out and Outlook complained about the url being too long. Now we're using version 8.13.2 and the link in _context.link_ seem to be encoded which is later on resolved and it's at this point it fails.

Any way to work around this or how to handle this issue?

---

<div class="post-metadata">

**Author:** ![blindahl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/blindahl/32/118231_2.png) [@blindahl](https://discuss.elastic.co/u/blindahl)\
**Post date:** [November 8, 2024, 7:46am UTC](https://discuss.elastic.co/t/context-link-generated-is-too-long-to-be-resolved/370157/2 "2024-11-08T07:46:12Z")

</div>

Ok, apparently this seem to be a known issue. Not sure if there's a workaround the issue though.

> <https://github.com/elastic/kibana/issues/158262>
>
> I did a test with the Slack connector, sending \`http://example.com/app/r?l=DISCO…VER\_APP\_LOCATOR&v=8.7.1&lz=1234567890\` with the \`1..0\` numbers repeated 400 times. Total of 4060 bytes. This is from a support case, for a use of \`{{context.link}}\` variable from an elasticsearch query rule in an action.
> 
> Slack split it into 3992 bytes in the first message, remainder in the second. We've seen that Slack has a 40K message limit, but this is below that. It's possible the 40K limit is the total limit of the message, but that there's a ~4K limit on line lengths, or something. I didn't see any mention of possible line length limits.
> 
> This was a change from 8.6.2 to 8.7.1, for one user's rule we looked at, where the URL went from 254 bytes to 1072 bytes. The same customer hit the "split line" problem with a URL \> 4000 bytes.
> 
> Seems like the change to the URL was made here: https://github.com/elastic/kibana/pull/146403
> 
> Generating links in the "saved objects" format will result in much smaller URLs, however that also means each of those queries will be persisted in an index, forever.
> 
> We'll need to figure out some story for these ...