Thank you, Robert! I think you are right about those NOISEWORDS. I tested against other words in that set and noticed the same behavior where %CONTAINS did not return results but the [ operator did. Appreciate the follow-up and detailed explanation!

Thank you for the responses. To clarify, I did read the documentation for %CONTAINS as a starting point before posting this question on the developer community.

The datatype of the column (property) I am using %CONTAINS on is of %Text and the LANGUAGECLASS is set to a custom class that extends %Text.English. 

Perhaps there is something in the docs that I'm missing that would cause the issue with the searching for the "time" word I'd mentioned above.

However, it seems like @Robert Cemper 's suggestion with using the [ operator achieves the same functionality I'm looking for with a similar performance time - when tested in the SQL page of the management portal.

Thanks for the input Nigel! The issue turned out to be caused by an HTTP interceptor from an imported library which would set the Content-Type to application/json if it was undefined.

Finally fixed the problem by adding a new HTTP interceptor to remove the Content-Type header if the request URL matched a specific pattern (i.e. contained "$upload"). Removing the Content-Type header allowed the Content-Type to get auto-detected as "multipart/form-data" and the boundary to get set when the request was sent.

@David Hockenbroch - Thanks for the reply!  

I was looking to create a calculated field since my Question class extends AppS.REST.Model.Adaptor and the JSON returned from the GET request 'api/standard/question' would include the class properties but not their relationships (e.g. Question.Document).

I ended up setting the docFileName property when creating a new Question instance - which seemed to be the easiest/most straightforward way to get the docFileName in the returned JSON.