MISSING_BUILD_TRIGGER_ID_PARAMETER , when it is present

Describe the issue:

Followed the steps from docs to set up site search:

  • Created new role whose permission is “Perform Site Search API calls”
  • Created token associated to that role with all permissions toggled to on
  • Using the information from above and the docs created the following fetch request:
import {buildClient} from "@datocms/cma-client-browser";

 const client = buildClient({apiToken: 'VALUE_FROM_ABOVE_BULLET_POINTS'});

      const {data: searchResults, meta} = await client.searchResults.rawList({
        filter: {
          fuzzy: true,
          query: query,
          build_trigger_id: 'XXXX', //Used the four digits found in the URL when viewing Project Settings > Triggers
          locale: locale,
        },
        page: {
          limit: 20,
          offset: 0,
        },
      });

      console.log(`Total results: ${meta.total_count}`);
      console.log(JSON.stringify(searchResults, null, 2));

Network request showcases the value is indeed sent:

image

Yet the response from the server indicates that the value is not sent:

Not sure how to proceed. Would you be able to help us with this?

Hi @technology,

Sorry, this appears to be a bug with our error messages (oh, the irony…). I’ll report that right away.

The actual issue is that your none of your build triggers have the “Enable Site Search” option enabled:

Could you please try:

  • Enabling that option for the build trigger you’re using
  • Running the build again from DatoCMS (the “Build status” button in the upper right)
  • Waiting a few minutes for the spider success notification
  • Trying the API call again

You can view detailed spider information in your project’s Build triggers activity in order to see what the spider is doing, if you need to.

But the bug is just that we’re showing you the wrong error message… you need to turn on site spidering in one or more build hooks for that API call to work.

Sorry about the confusion!

1 Like

:joy:

No worries, thanks for getting back to us so quickly. I’ll try out the suggestion first thing tomorrow morning and come back to report on results. Cheers!

1 Like

That was it, thank you!

1 Like

As long as we are on the same thread, I looked through docs , and it seems it’s not possible to get thumbnails for the search results, correct? (just wanted to double check)

Thumbnail, like a screenshot? Unfortunately, no… our crawler is a very basic one that only looks at the rendered HTML. It doesn’t actually run a browser, so it can’t take a screenshot :frowning: You’d have to use a third-party system for that, sorry!

Something like a serverless worker might be able to do it, but you have to set this up on your own: https://developers.cloudflare.com/browser-rendering/workers-binding-api/screenshots/

(You can also run Playwright/Puppeteer/Selenium/etc. on your own machine or VPS and do it that way, but it’s again a script you’d have to write and maintain on your own, sorry!)

Just an update on this (the original MISSING_BUILD_TRIGGER_ID_PARAMETER error, which was wrong and confusing).

We couldn’t modify the underlying API behavior without breaking backward compatibility for existing users. So, instead, we updated the error code and explanation.

The error code MISSING_BUILD_TRIGGER_ID_PARAMETER is now deprecated in favor of the clearer UNRESOLVABLE_BUILD_TRIGGER: CMA Error Codes (REST) | Documentation — DatoCMS

UNRESOLVABLE_BUILD_TRIGGER
This error occurs when a Site Search API call fails due to DatoCMS’s inability to identify a valid, search-enabled build trigger. If your request includes a filter[build_trigger_id] query string parameter, this error indicates that either the ID is incorrect, or the build trigger does not have the “Enable Site Search” option checked. If your request does NOT include a build_trigger_id parameter, then the API cannot select a default build trigger because there are either no search-enabled build triggers available or multiple ones, leading to an ambiguity it cannot resolve.

The underlying behavior did not change, but hopefully the fallbacks are better explained now.

TLDR, easy solution: Just make sure the build trigger you’re using actually has site search enabled; don’t make the system try to guess which one to use :slight_smile: