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

Error in statusboard::run_app(): 'id variables not found in data: Workflow_id' #19

Open
Sweetdevil144 opened this issue Mar 20, 2024 · 0 comments

Comments

@Sweetdevil144
Copy link
Contributor

Description

Encountering repeated errors when using statusboard::run_app() in the PEcAn project. This issue seems to be a common point of failure in our runs with the following error message:

Warning: Error in : id variables not found in data: Workflow_id
  52: stop
  51: melt_check
  50: melt.data.frame
  48: module
  43: callModule
  42: moduleServer
  41: mod_workflows_satus_server
  40: server
   3: runApp
   2: print.shiny.appobj
   1: <Anonymous>
Error: id variables not found in data: Workflow_id

Notice the stack calls made which start from either R/app_server.R OR R/mod_workflows_status.R.

Steps to Reproduce

  1. Run statusboard::run_app() after running library(statusboard)
  2. Any other steps or conditions under which the error occurs, i.e, similar further cases where error messgae may pinpoint to two or more different error origins.

Expected Behavior

If we were to create specifc error messages and specific test cases for each of our /R/*.R files beforehand, we'd find ease to pinpoint exact origins of errors in such scenarios.

Actual Behavior

The application fails to run, showing the error message related to missing 'Workflow_id' in the data.

Possible Solution (Proposal)

I'd like to propose crafting specific test cases for such condition specific functions to ease the process of debugging.

This error could be indicative of an issue with the data structure expected by the melt.data.frame function or the input provided to it. Debugging each file involved in the stack trace could help locate the exact source of the error. For instance:

  • Implementing specific test cases for each file mentioned in the stack trace, such as R/app_server.R and R/mod_workflows_status.R.
  • Adding distinct error messages in each of these files might help pinpoint the exact location and cause of the error.

This approach should make it easier to identify whether the issue is with the data being passed to the function or within the function itself.

New WARNING logs noticed. Notice the stack calls made which start from either R/app_server.R OR R/mod_workflows_status.R.

Originally posted in #13 over here : #13 (comment)

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

No branches or pull requests

1 participant