You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The client sometimes requests a new version of the argument graph before it has finished
being drawn. When that happens, some just added nodes appear to the far left of the diagram,
not connected to the rest of the graph, and the probabilities might not have been updated.
The problem is with rypc_server.GraphRequest. It calls draw_graph() directly on a reference to the
ArgumentGraph object from the AllsemblyServer's thread. Instead, it should load its own ArgumentGraph object
from the committed version in the database.
The client call to the API to get the updated graph should return the
graph together with a revision number. Then future calls will
include the last revision number that the client received, and if no new graph is available,
the call can return with XML containing that information. Then,
only in that case, the client-side Javascript will wait and try
again. Ideally, the information will include whether an update
is in progress or whether no update is expected. If a change
had been requested but no update is expected, then the client
can resubmit the change. Additional details such as request
numbers and request receipts can be used to guard the integrity
of the data and robustness of processing. See the heading "Design for Integrity" in the Programmer's Guide of
the documentation for initial thoughts about ensuring that the server records requests accurately and
completely. Additionally, the client should digitally sign requests (to keep it accountable) and the
server should likewise digitally sign receipts.
There is a workaround in commit 5d7725e (in the django-version branch).
The text was updated successfully, but these errors were encountered:
commit 42e946c (which is currently in the django-version branch) fixes just the part:
"The problem is with rypc_server.GraphRequest. It calls draw_graph() directly on a reference to the
ArgumentGraph object from the AllsemblyServer's thread. Instead, it should load its own ArgumentGraph object
from the committed version in the database."
Tracking and checking a revision number is future work.
The client sometimes requests a new version of the argument graph before it has finished
being drawn. When that happens, some just added nodes appear to the far left of the diagram,
not connected to the rest of the graph, and the probabilities might not have been updated.
The problem is with rypc_server.GraphRequest. It calls draw_graph() directly on a reference to the
ArgumentGraph object from the AllsemblyServer's thread. Instead, it should load its own ArgumentGraph object
from the committed version in the database.
The client call to the API to get the updated graph should return the
graph together with a revision number. Then future calls will
include the last revision number that the client received, and if no new graph is available,
the call can return with XML containing that information. Then,
only in that case, the client-side Javascript will wait and try
again. Ideally, the information will include whether an update
is in progress or whether no update is expected. If a change
had been requested but no update is expected, then the client
can resubmit the change. Additional details such as request
numbers and request receipts can be used to guard the integrity
of the data and robustness of processing. See the heading "Design for Integrity" in the Programmer's Guide of
the documentation for initial thoughts about ensuring that the server records requests accurately and
completely. Additionally, the client should digitally sign requests (to keep it accountable) and the
server should likewise digitally sign receipts.
There is a workaround in commit 5d7725e (in the django-version branch).
The text was updated successfully, but these errors were encountered: