2016 - 2019 - Wrong SSRS Instance Processing Report Render Request

I have inherited a very weird anomaly in SSRS. A new SSRS instance was created using 2019 and it appears it is using the same ReportServer DB as previous 2016 instance. This may have been done to avoid porting thousands of reports and associated items.

• The 2016 instance seems to still be running, however, the account used to access the ReportingService db is no longer valid, thus any attempts to access a report using the 2016 url end with a 'cannot access the report server database.'

• When I access a report in 2019 I can render it in the report manager.

• When I invoke the same report, using the 2019 instance's url, through a wcf service call to ReportService2010.Render(), I get the same error as if I were accessing the services vis the 2016 instance.

• Alos, I know the 2016 version is trying to render the call made to 2019 because the log information about the render attempt and "can't connect to report server database" error only show up in 2016's error log.

• I have re-checked the iis log and see the that the wcf service is calling the 2019 server to request the render with 200 result (it is fire and forget so a 200 is always returned if the endpoint is accessible).

It seems like the wcf is in fact calling the 2019 instance and requesting a report, however, the logging for that request is being done over at the 2016 instance of SSRS.

Could this be something not well configured in the report sever database?

This was user error. The app.config for the WCF service was pointing to the correct instance, hence the correct logging messages. The web.config in the API project, which referenced all WCF services, had two app settings with the same key. One key was incorrect and that was used for the ReportExecution endpoint binding.

I assumed the configs were pristine.