Error messages incorrectly displaying

[tylervz]

Sometimes when submitting a document to print, an error message will appear saying "Sorry! Something went wrong while we were submitting your print job. Please try again", but when the user refreshes the page, their queue shows that the document was successfully submitted to uniFLOW.

[twodarek]

Are there particular circumstances that bring this about? Steps to repro would be helpful in this case.

[jglamine]

I've also encountered this. No idea how to reproduce it. This is where good
logging would come in handy.
On May 2, 2015 9:49 PM, "Thomas Wodarek" notifications@github.com wrote:

Are there particular circumstances that bring this about? Steps to repro
would be helpful in this case.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

[tylervz]

I think has a higher chance of occurring when submitting PDF files. It might even only happen when submitting PDF files.

[jglamine]

I think the first step is to implement some logging so that whenever
submission fails, a message is logged. That way we know why it's failing.

Remember how we poll the cloudprint history to check if something actually
uploaded? We set the time limit to 30 seconds. Maybe it's succeeding, but
not showing up within those 30 seconds.

There's no way of knowing untill we have better logging. So the first step
is to ship some logging code, and then we can look at the logs.
On May 3, 2015 3:31 PM, "Tyler VanZanten" notifications@github.com wrote:

I think has a higher chance of occurring when submitting PDF files. It
might even only happen when submitting PDF files.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

[tylervz]

I'm pretty sure I figured it out. It is because in cloudprint.py the function _wait_for_job_processing() is not waiting long enough for larger files like PDFs.

[jglamine]

Yah, that's probably it.
On May 3, 2015 3:40 PM, "Tyler VanZanten" notifications@github.com wrote:

I'm pretty sure I figured it out. It is because in cloudprint.py the
function _wait_for_job_processing() is not waiting long enough for larger
files like PDFs.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

[tylervz]

Another problem with _wait_for_job_processing() is that is runs a for loop through a user's Google Cloud Print history and that history never gets deleted (by us).

[jglamine]

Do you think processing time increases linearly with file size? If so, it
should be easy to make the wait time change depending on file size. Perhaps
write a script to test how long it takes different files to upload and see
if the data fits a linear regression model.
On May 3, 2015 3:41 PM, jglamine@gmail.com wrote:

Yah, that's probably it.
On May 3, 2015 3:40 PM, "Tyler VanZanten" notifications@github.com
wrote:

I'm pretty sure I figured it out. It is because in cloudprint.py the
function _wait_for_job_processing() is not waiting long enough for
larger files like PDFs.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

[jglamine]

What's wrong with not deleting cloud print history? Does it break if
someone uploads the same file twice?
On May 3, 2015 3:45 PM, "James Lamine" jglamine@gmail.com wrote:

Do you think processing time increases linearly with file size? If so, it
should be easy to make the wait time change depending on file size. Perhaps
write a script to test how long it takes different files to upload and see
if the data fits a linear regression model.
On May 3, 2015 3:41 PM, jglamine@gmail.com wrote:

Yah, that's probably it.
On May 3, 2015 3:40 PM, "Tyler VanZanten" notifications@github.com
wrote:

I'm pretty sure I figured it out. It is because in cloudprint.py the
function _wait_for_job_processing() is not waiting long enough for
larger files like PDFs.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.

[tylervz]

Yeah I'd guess processing time increases linearly with file size.

[tylervz]

Never mind about the cloud print history. Being slower would be beneficial in this case. Sort of.