Prospect add SDK to their python code and every thing was great till they switch off the debug mode flag.
Is that a must to work with debug on or we miss something here?
With -d 1
Without -d 1
@email@example.com & yos
Solved! Go to Solution.
This -d flag is something specific to the wsgi_main.py script the prospect is using. Any behavior changes that result from it are application specific (or framework specific). Theoretically, the prospect could even intentionally disable the SDK outside debug mode. In summary, I can't say why it doesn't work because this is an application-specific flag/issue.
The prospect should make sure the SDK functions are called also when the -d flag is not set, if that is the intention.
Christian N. (Developer @ OneAgent SDK Team)
Thanks for your answer and insight.
that the code goes through the SDK calls by adding log lines and they were
Prospect also added that the code diff for debug/no debug is as follows:
if cbprm.DEBUG or _b_debug:
wsgiref_server(application, _host, port)else:gevent_server(application, port)
I don't know gevent myself, but it says on the homepage that it's coroutine based. This could unfortunately mean that it is effectively impossible to maintain the following requirement that is imposed by the SDK:
A tracer can only be used on the thread (i.e., Operating System Thread, not green thread or the like) it was created on (this also means, in a Python `with tracer`-block, entering and leaving the block must happen in the same thread).
Even after doing this (if possible) the prospect may get problems with paths that are unintentionally nested because when starting a tracer, it will automatically and unavoidably become a child tracer of any tracer that is currently started on this thread. This could very well lead to bad paths because coroutine based webframeworks usually interleave processing of multiple webrequest on the same OS thread.
EDIT: A workaround would be to end the tracer right after starting it when receiving the request, without calling `yield` or otherwise doing a context switch or the like in between. This way, at least request information could be reliably captured but probably not response information and the timings will be off of course. (end EDIT)
The customer could try setting a diagnostic callback, as described here:
The messages passed to it could help debugging this issue / confirming that my above suspicion is true.