I just got back to chasing this further and found my own answer.

I found a piece of code out on the web, which used the sdbus to send a message, which I was able to get working successfully. I then started working backwards to figure out what the difference was between my code and theirs and was able to narrow it down to the request_handler() function that was called when the sendRequest entry in my VTABLE was hit. In the request_handler() function, I had some local variables that were uninitialized. I found that when I initialized these local variables to zero, when they were declared, that the error messages I was seeing in the log went away.

I'm not exactly sure what was going on, under the hood, that led to the error messages in the journal output, but after initializing these variables, the errors are gone. It looks like the uninitialized variables led to some undefined behavior, that manifested itself in a very unexpected and cryptic fashion.

It is probably worth mentioning, that I found a tool called d-spy, which was very useful in the debugging process. It is a tool intended to help explore d-bus connections, and can be used to execute and invoke methods on an interface, on both the session or system bus. It can be found here: https://flathub.org/apps/org.gnome.dspy

Here is how I would test the set up of my interface, and invoke methods: