Potential Bug with skuid.sfdc.search() and sosl query generation in Brooklyn?

We are working on upgrading from Rockaway 8.15.17 to Brooklyn 9.5.6 (we have a dev and qa sandbox, dev is using Brooklyn and qa is still on Rockaway). We have some custom components that stopped working in our dev environment after the upgrade to Brooklyn and we’ve got most of the issues ironed out except for one, which appears to be a bug with Skuid’s sfdc.search(…) function.

Our code is virtually identical to what’s in the documentation here: https://docs.skuid.com/latest/en/skuid/api/skuid_sfdc.html

However, even though we pass the same request object in both Rockaway and Brooklyn, the sosl that the search(…) function builds is wrong…the sosl isn’t complete and we get an “unexpected token: ‘’” error as a result.

Example:

The sosl in Rockaway:

  • ``` FIND 'CasePriority*' IN NAME FIELDS RETURNING Skuid_Picklist_Value__c(Name,Value__c) ```
The sosl in Brooklyn:
  • ``` FIND '*' IN NAME FIELDS RETURNING ```
Here's the full method call we're using, in case it helps:
skuid.$.when(skuid.sfdc.search({ query: "CasePriority", searching: "NAME FIELDS", returning: [{ "objectName": "Skuid_Picklist_Value__c", "fields": ["Name", "Value__c"] }] })).done(function(searchResult) { /* skipping the complex stuff that would normally be here, for the sake of this email, and just logging the result */ console.log("SEARCHRESULT:"); console.log (searchResult); }).fail(function(searchResult) { console.error('Search failed: ' + searchResult.error); }).always(function(searchResult) { console.log('Raw SOSL generated: ' + searchResult.sosl); console.log('Original search request'); console.log(searchResult.request); });
Has anyone else experienced this? We're reaching out to Skuid's support people as well, but thought it wise to ask here as well...

Any thoughts? Thanks in advance.

Just to be clear, we have no control of the SOSL that gets generated. The skuid.sfdc.search(…) function builds it based on the request object that gets passed in.

Update: after a week and a half of messing with this, we decided to try upgrading Brooklyn to 9.5.7 and it looks like the issue is fixed there.