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

edited July 2017 in Problems
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: '<EOF>'" 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.

Comments

  • edited June 2017
    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.
  • edited June 2017
    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.
Sign In or Register to comment.