Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add debugging message for #443 #448

Merged
merged 1 commit into from
Mar 17, 2021
Merged

Add debugging message for #443 #448

merged 1 commit into from
Mar 17, 2021

Conversation

0x2b3bfa0
Copy link
Member

This pull request doesn't fix #443 per se and is only intended to facilitate bug reports if the mentioned issue can be reproduced in the future.

@0x2b3bfa0 0x2b3bfa0 requested a review from DavidGOrtega March 17, 2021 13:44
src/utils.js Outdated
@@ -78,6 +78,13 @@ const upload = async (opts) => {
const response = await fetch(endpoint, { method: 'POST', headers, body });
const uri = await response.text();

if (!uri) {
console.log(response);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not log here and would throw the error message

Copy link
Member Author

@0x2b3bfa0 0x2b3bfa0 Mar 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DavidGOrtega, the issue is that there is no error message, but just an allegedly successful response with an empty body. That's why I chose to log the whole response object: it may contain precious information that might be hard to obtain on a (probably) intermittent bug like this.

Would you like to integrate it into the error message or just extract some properties?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not log using console.log we should use a logging instead.
The error should bubble the issue to a better handler.
This is a technical debt that we have to solve with #22

  • no console.log
  • no log that can not be display by debug, info, error levels...
  • prepare everything for json outputs choosing the right std (another log would break the output)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the issue is that there is no error message, but just an allegedly successful response with an empty body. That's why I chose to log the whole response object: it may contain precious information that might be hard to obtain on a (probably) intermittent bug like this.

Let's advise that the request to the storage failed. I wonder if we could not also retry at least once 🤔

Copy link
Member Author

@0x2b3bfa0 0x2b3bfa0 Mar 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not log using console.log we should use a logging instead.

Agreed! I used a plain log call because we haven't moved yet to winston as you proposed if I recall correctly.

The error should bubble the issue to a better handler.

Then, I guess that we should just throw an error with templated information and let the handler do the rest.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not say it's not reliable, my guess is that its overloaded as any other SAAS.

With the current backend architecture, I struggle to find how a possible overload would produce an empty succesful reply. Anyhow, we can't discard that possibility.

I would put that defense in order to protect the workflow. Take into account that if the user is not setting any kind of model cache she would have to redo the whole training because the asset did not uploaded at the end of the workflow.

That's a really good point, though I don't know if this event is frequent enough to justify this kind of safeguard. I wouldn't be concerned at all by this if we could silently send the error through a telemetry system, but I suspect that #443 won't happen that often and it could be more beneficial in the long run to produce an error, ask users to report, and fix the issue whenever possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I struggle to find how a possible overload would produce an empty succesful reply.

Do you have the code finally?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😆 where is it?

Copy link
Member Author

@0x2b3bfa0 0x2b3bfa0 Mar 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here. 😂 Sorry for the opaque reply, I thought that you noticed the thread in Slack.

src/utils.js Outdated Show resolved Hide resolved
This commit doesn't fix #443, but closes it until we can reproduce again the error.
Copy link
Contributor

@DavidGOrtega DavidGOrtega left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm

@0x2b3bfa0 0x2b3bfa0 changed the base branch from master to release/v0.3.1 March 17, 2021 15:26
@0x2b3bfa0 0x2b3bfa0 self-assigned this Mar 17, 2021
@0x2b3bfa0 0x2b3bfa0 added this to the 0.3.1 milestone Mar 17, 2021
@0x2b3bfa0 0x2b3bfa0 merged commit 35d5f4e into release/v0.3.1 Mar 17, 2021
@0x2b3bfa0 0x2b3bfa0 deleted the debug-issue-443 branch March 17, 2021 15:33
DavidGOrtega added a commit that referenced this pull request Mar 18, 2021
…#431)

* [create-pull-request] automated change (#425)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Update dependacron pull request step (#426)

This commit updates the major version for the peter-evans/create-pull-request GitHub Action step.

Required in order to avoid a fatal error caused by the  hard deprecation of the `set-env` and `add-path` standard output commands after CVE-2020-15228.

* Add sanity check for cml-publish with filesystem paths (#427)

* Add sanity check for cml-publish files

Closes #308 and probably also closes #401

* Restyled by prettier (#428)

Co-authored-by: Restyled.io <[email protected]>

* Add tests for cml-publish file errors

* Also removes an stray leading dot on the introduced error message

* Embrace native file error messages for cml-publish

Co-authored-by: restyled-io[bot] <32688539+restyled-io[bot]@users.noreply.github.com>
Co-authored-by: Restyled.io <[email protected]>

* Add destroy timeout feature (#419)

* [create-pull-request] automated change (#441)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Helio Machado <[email protected]>

* Add support for singleton runners (#422)

* Add support for singleton runners

The --reuse-existing flag will cause cml-runner
to look up for already existing runners with the
specified --labels and skip creating a new one
if that's the case.

* Deprecate --name with a warning

* Apply pre-review suggestions and fixes

* Comment out deprecation warning
* Remove unnecessary comparison
* Rename reuse-existing to reuse
* Fix misconception about empty array truthiness
* Simplify reuse by name logic
* Add missing awaits
* Give precedence to name deduplication over label deduplication
* Remove commented code

* Startup script (#445)

* Startup script

* lint

* snapshots

* Add debugging message for #443 (#448)

This commit doesn't completely fix #443, but closes it until we can reproduce again the error.

* Bitbucket-1000-handling

* bump version

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: restyled-io[bot] <32688539+restyled-io[bot]@users.noreply.github.com>
Co-authored-by: Restyled.io <[email protected]>
Co-authored-by: DavidGOrtega <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

cml-publish ERR_INVALID_URL
2 participants