How Do I Fix "assertion failed: " During OSLC Discovery?

I have used the OSLC “discovery mechanism” in the past as discussed on several wiki pages and posts on Jazz.net. Under OSLC, you send the server an http request on the “discovery” url and the server responds with a  list of services that it has available. You then pick one of those services and send another request on that URL. You kind of “drill down” through several discovery layers to find out information about the server (e.g., what kinds of work items are available, what projects are present, what url to use for OSLC queries, etc…). Although this has worked in the past, today I am seeing that the server is not responding to one of the basic discovery requests in the way that is expected. This is what I’m seeing:

Client:
HTTP GET using https://[our server url:port]/ccm/oslc/workitems/catalog.xml

Server:
Responds as expected with an xml file that lists the project areas.  
 
Client:
The client picks one of the project areas that was returned from the sender and requests the “services.xml” associated with that project area. For example:
HTTP GET using https://[our server url:port]/ccm/oslc/contexts/_3ual1BiuEek3hs2s7AEXnQ/workitems/services.xml
(note that _3ual1BiuEek3hs2s7AEXnQ is the project identifier for the selected project area).
 
At this point, the server is SUPPOSED to return another XML file that provides a bunch of available services for that particular project area. Instead I am getting this:

<?xml version=”1.0” encoding=”UTF-8”?>
<oslc_cm:error xmlns:oslc_cm=http://open-services.net/xmlns/cm/1.0/>
     <oslc_cm:status>500</oslc_cm:status>
     <oslc_cm:message>assertion failed: </oslc_cm:message>
</oslc_cm:error>

I believe this is supposed to work up to this point regardless of whether or not the OSLC-Core-Version: 2.0 header is set, but I've tried it both ways just in case. It doesn't seem to make a difference.

Has anyone encountered this issue before? Is there a fix without a server restart? I have not had an opportunity to issue a server restart yet (there are too many active users who are not impacted by this discovery mechanism deficiency), but am hopeful that will fix it. This kind of issue negatively impacts our information assurance (e.g., availability).