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

fix: simplified error handling in build-dashboard.js #3521

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

sahitya-chandra
Copy link

@sahitya-chandra sahitya-chandra commented Dec 28, 2024

Description

error logging img
Screenshot from 2024-12-31 19-05-15

  • added the cleaning up before and after the test in to fix the failing of tests build-pages.test.js file

Related issue(s)
resolved #3305 #3358

Summary by CodeRabbit

Summary by CodeRabbit

  • New Features

    • Introduced a logging utility for improved error tracking and management.
    • Added structured logging capabilities to enhance traceability of issues.
  • Bug Fixes

    • Improved error handling mechanisms in dashboard build script.
    • Enhanced error propagation for more robust error management during tool processing.
  • Tests

    • Improved setup and teardown processes for test directories to ensure reliability.

Copy link

coderabbitai bot commented Dec 28, 2024

Walkthrough

The changes focus on modifying error handling in the build-dashboard.js script. The primary modification involves replacing Promise.reject(e) with direct error throwing (throw e) in several functions including getDiscussions, getDiscussionByID, and processHotDiscussions. This approach changes how errors are propagated through the asynchronous functions, making the error handling more straightforward and aligned with modern JavaScript error management practices. Additionally, a new logging utility is introduced, and the package.json is updated to include the winston library for enhanced logging capabilities.

Changes

File Change Summary
scripts/dashboard/build-dashboard.js Updated error handling in getDiscussions, getDiscussionByID, and processHotDiscussions to throw errors directly instead of using Promise.reject().
package.json Added dependency for "winston": "^3.17.0" to enable logging features.
scripts/tools/logger.js Introduced a new logging utility configured with winston for structured logging.
scripts/tools/tools-object.js Integrated logging into convertTools function to log errors during processing.
tests/build-pages.test.js Enhanced test setup by managing temporary directories for isolation, adding NEW_TEST_DIR.

Assessment against linked issues

Objective Addressed Explanation
Simplify error handling [#3305]

Possibly related PRs

  • feat: add tests for build post list script #3284: This PR introduces tests for the build-post-list.js script, which may relate to error handling improvements in the main PR, particularly if the tests cover scenarios similar to those in the modified functions (getDiscussions, getDiscussionByID, and processHotDiscussions).
  • feat: increase code coverage #3517: This PR enhances code coverage, which could include tests for error handling in various scripts, potentially overlapping with the error handling changes made in the main PR.

Suggested labels

ready-to-merge, gsoc

Suggested reviewers

  • sambhavgupta0705
  • derberg
  • magicmatatjahu
  • devilkiller-ag
  • asyncapi-bot-eve

Poem

🐰 In the script where errors once did hide,
Now they leap forth, no longer denied.
With logging bright, we trace every call,
A rabbit's code, standing proud and tall!
Clarity reigns, as we code and play,
In the land of scripts, it's a joyful day! 🚀

Tip

CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command @coderabbitai generate docstrings to have CodeRabbit automatically generate docstrings for your pull request. We would love to hear your feedback on Discord.


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

Copy link

netlify bot commented Dec 28, 2024

Deploy Preview for asyncapi-website ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 562be7a
🔍 Latest deploy log https://app.netlify.com/sites/asyncapi-website/deploys/67740df3afe8d50008dc873e
😎 Deploy Preview https://deploy-preview-3521--asyncapi-website.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@asyncapi-bot
Copy link
Contributor

asyncapi-bot commented Dec 28, 2024

⚡️ Lighthouse report for the changes in this PR:

Category Score
🔴 Performance 31
🟢 Accessibility 98
🟢 Best practices 92
🟢 SEO 100
🔴 PWA 33

Lighthouse ran on https://deploy-preview-3521--asyncapi-website.netlify.app/

Copy link

codecov bot commented Dec 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (fb0a3bf) to head (562be7a).

Additional details and impacted files
@@            Coverage Diff            @@
##            master     #3521   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           19        20    +1     
  Lines          668       673    +5     
=========================================
+ Hits           668       673    +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@sahitya-chandra sahitya-chandra changed the title fix:simplified error handling in build-dashboard.js fix: simplified error handling in build-dashboard.js Dec 28, 2024
@sahitya-chandra
Copy link
Author

@sambhavgupta0705 @devilkiller-ag Can you please review this.

Copy link
Member

@devilkiller-ag devilkiller-ag left a comment

Choose a reason for hiding this comment

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

LGTM!

@sahitya-chandra
Copy link
Author

sahitya-chandra commented Dec 30, 2024

@devilkiller-ag Sorry Sir I requested for review again... It happened by mistake.
Can you please approve this again.

@sambhavgupta0705
Copy link
Member

@sahitya-chandra why are we having these changes?

@sahitya-chandra
Copy link
Author

@sahitya-chandra why are we having these changes?

@sambhavgupta0705 Sir the code is returning a promise with error instead we can just throw an error

@sahitya-chandra
Copy link
Author

I have just simplified the error handling in build-dashboard.js file as mentioned in #3305 issue

@sambhavgupta0705
Copy link
Member

we are using async/await so yes we can use this throw here

@sambhavgupta0705
Copy link
Member

/update

@sahitya-chandra
Copy link
Author

sahitya-chandra commented Dec 30, 2024

@sambhavgupta0705 @devilkiller-ag thanks for the review sir.

Copy link
Member

@sambhavgupta0705 sambhavgupta0705 left a comment

Choose a reason for hiding this comment

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

LGTM

@sambhavgupta0705
Copy link
Member

@anshgoyalevil can you please take a look at this

@anshgoyalevil
Copy link
Member

This does solve the linked issue, but we are still looking for a better error handling strategy. Can we get #3358 done instead of just getting this promise thing modified?

@sahitya-chandra
Copy link
Author

This does solve the linked issue, but we are still looking for a better error handling strategy. Can we get #3358 done instead of just getting this promise thing modified?

Ok sir once I understand #3358 issue I will let you know...

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (4)
scripts/tools/logger.js (1)

1-19: Consider adjusting the formatting to meet Prettier style requirements.

According to the static analysis hints, the file should avoid multiline bracket formatting in lines 5-8 and 11-14 and remove the trailing comma on line 16. Implementing these suggestions will keep the codebase consistent.

Here is a potential diff to adjust the formatting:

 const logger = createLogger({
   level: 'error', // minimum level
-  format: format.combine(
-    format.timestamp(),
-    format.json()
-  ),
+  format: format.combine(format.timestamp(), format.json()),
   transports: [
     new transports.Console({
-      format: format.combine(
-        format.colorize(),
-        format.simple()
-      )
+      format: format.combine(format.colorize(), format.simple())
     })
-  ],
+  ]
 });
🧰 Tools
🪛 eslint

[error] 5-8: Replace ⏎····format.timestamp(),⏎····format.json()⏎·· with format.timestamp(),·format.json()

(prettier/prettier)


[error] 11-14: Replace ⏎········format.colorize(),⏎········format.simple()⏎······ with format.colorize(),·format.simple()

(prettier/prettier)


[error] 16-16: Delete ,

(prettier/prettier)


[error] 19-19: Insert

(prettier/prettier)

tests/build-pages.test.js (2)

26-32: Use arrow function parentheses for clarity.

For the callback in [TEST_DIR, NEW_TEST_DIR].forEach(dir => { ... }), consider adding parentheses around the parameter for readability. This aligns with Prettier’s recommended styling.

-[TEST_DIR, NEW_TEST_DIR].forEach(dir => {
+[TEST_DIR, NEW_TEST_DIR].forEach((dir) => {
🧰 Tools
🪛 eslint

[error] 26-27: Replace ⏎····[TEST_DIR,·NEW_TEST_DIR].forEach(dir with ····[TEST_DIR,·NEW_TEST_DIR].forEach((dir)

(prettier/prettier)


44-50: Similarly apply arrow function parentheses.

We can mirror the same style in the afterAll callback for consistency.

🧰 Tools
🪛 eslint

[error] 44-45: Replace ⏎····[TEST_DIR,·NEW_TEST_DIR].forEach(dir with ····[TEST_DIR,·NEW_TEST_DIR].forEach((dir)

(prettier/prettier)


[error] 50-50: Delete ····

(prettier/prettier)

scripts/tools/tools-object.js (1)

11-11: Replace ".js" extension for consistency.

The static analysis suggests avoiding explicit file extensions. Using './logger' instead of './logger.js' is an option if the codebase style allows it.

-const logger = require("./logger.js");
+const logger = require("./logger");
🧰 Tools
🪛 eslint

[error] 11-11: Replace "./logger.js" with './logger.js'

(prettier/prettier)


[error] 11-11: Unexpected use of file extension "js" for "./logger.js"

(import/extensions)

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ee5b5cc and 5b1388e.

⛔ Files ignored due to path filters (1)
  • package-lock.json is excluded by !**/package-lock.json
📒 Files selected for processing (4)
  • package.json (1 hunks)
  • scripts/tools/logger.js (1 hunks)
  • scripts/tools/tools-object.js (2 hunks)
  • tests/build-pages.test.js (3 hunks)
🧰 Additional context used
🪛 eslint
scripts/tools/logger.js

[error] 5-8: Replace ⏎····format.timestamp(),⏎····format.json()⏎·· with format.timestamp(),·format.json()

(prettier/prettier)


[error] 11-14: Replace ⏎········format.colorize(),⏎········format.simple()⏎······ with format.colorize(),·format.simple()

(prettier/prettier)


[error] 16-16: Delete ,

(prettier/prettier)


[error] 19-19: Insert

(prettier/prettier)

scripts/tools/tools-object.js

[error] 11-11: Replace "./logger.js" with './logger.js'

(prettier/prettier)


[error] 11-11: Unexpected use of file extension "js" for "./logger.js"

(import/extensions)


[error] 111-111: Insert );⏎

(prettier/prettier)


[error] 117-117: Delete ,

(prettier/prettier)

tests/build-pages.test.js

[error] 26-27: Replace ⏎····[TEST_DIR,·NEW_TEST_DIR].forEach(dir with ····[TEST_DIR,·NEW_TEST_DIR].forEach((dir)

(prettier/prettier)


[error] 44-45: Replace ⏎····[TEST_DIR,·NEW_TEST_DIR].forEach(dir with ····[TEST_DIR,·NEW_TEST_DIR].forEach((dir)

(prettier/prettier)


[error] 50-50: Delete ····

(prettier/prettier)


[error] 65-66: Delete

(prettier/prettier)

🔇 Additional comments (4)
tests/build-pages.test.js (2)

23-23: New constant introduced for directory handling.

Defining NEW_TEST_DIR segregates it from TEST_DIR, improving clarity in test directory setup. This looks good.


65-68: Ensure directory is always cleaned up.

This test effectively verifies ensureDirectoryExists. The explicit cleanup of NEW_TEST_DIR is a good safety check. No issues here.

🧰 Tools
🪛 eslint

[error] 65-66: Delete

(prettier/prettier)

scripts/tools/tools-object.js (1)

114-118: Structured logging is well-implemented.

Logging the message, stack, and phase helps debugging. This integration with Winston is properly done. Great job.

🧰 Tools
🪛 eslint

[error] 117-117: Delete ,

(prettier/prettier)

package.json (1)

118-118: Dependency addition recognized.

The winston library is widely used for logging. Including it here makes sense to support structured logging as implemented in scripts/tools/logger.js.

@sahitya-chandra
Copy link
Author

sahitya-chandra commented Dec 31, 2024

@anshgoyalevil Please have a look sir...
I think the #3358 issue will be resolved after this

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Nitpick comments (4)
scripts/tools/logger.js (1)

3-11: Consider enhancing logger configuration for better observability

The Winston logger setup implements good practices with structured logging (JSON format + timestamp). However, consider these enhancements:

  1. The 'error' level might miss important warnings. Consider using 'info' as the base level and filtering at the transport level.
  2. Add file transport for persistent logging in production.
 const logger = createLogger({
-  level: 'error', // minimum level of messages logger will handle
+  level: 'info', // capture all important logs
   format: format.combine(format.timestamp(), format.json()),
   transports: [
     new transports.Console({
+      level: 'error', // filter console output to errors
       format: format.combine(format.colorize(), format.simple())
-    })
+    }),
+    new transports.File({
+      filename: 'error.log',
+      level: 'error',
+      format: format.combine(
+        format.timestamp(),
+        format.json()
+      )
+    })
   ]
 });
scripts/tools/tools-object.js (2)

11-11: Fix quote consistency

Use single quotes consistently across the file.

-const logger = require("./logger");
+const logger = require('./logger');
🧰 Tools
🪛 eslint

[error] 11-11: Replace "./logger" with './logger'

(prettier/prettier)


Line range hint 89-91: Standardize error handling approach

The nested try-catch blocks have inconsistent error handling approaches. The inner catch throws directly while the outer catch logs and wraps. Consider standardizing the approach.

      } catch (err) {
-       console.error(err)
-       throw err;
+       logger.error('Error processing individual tool', {
+         message: err.message,
+         stack: err.stack,
+         phase: 'individual_tool_processing',
+       });
+       throw new Error(`Error processing individual tool: ${err.message}`);
      }
    }))
    
    return finalToolsObject;
  } catch (err) {
    logger.error('Error processing tool', {
      message: err.message,
      stack: err.stack,
      phase: 'tool_processing',
    });
    throw new Error(`Error processing tool: ${err.message}`)
  }

Also applies to: 111-120

🧰 Tools
🪛 eslint

[error] 8-8: Replace "uri"]) with 'uri']);

(prettier/prettier)


[error] 9-9: Insert ;

(prettier/prettier)


[error] 11-11: Replace "./logger" with './logger'

(prettier/prettier)

tests/build-pages.test.js (1)

27-31: Optimize test cleanup code

The directory cleanup logic is duplicated in beforeAll and afterAll. Consider extracting it to a helper function.

+const cleanupTestDirs = () => {
+  [TEST_DIR, NEW_TEST_DIR].forEach((dir) => {
+    if (fs.existsSync(dir)) {
+      fs.rmSync(dir, { recursive: true, force: true });
+    }
+  });
+};

 beforeAll(() => {
-  [TEST_DIR, NEW_TEST_DIR].forEach((dir) => {
-    if (fs.existsSync(dir)) {
-      fs.rmSync(dir, { recursive: true, force: true });
-    }
-  });
+  cleanupTestDirs();
   // ... rest of setup
 });

 afterAll(() => {
-  [TEST_DIR, NEW_TEST_DIR].forEach(dir => {
-    if (fs.existsSync(dir)) {
-      fs.rmSync(dir, { recursive: true, force: true });
-    }
-  });
+  cleanupTestDirs();
 });

Also applies to: 45-49

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5b1388e and 562be7a.

📒 Files selected for processing (3)
  • scripts/tools/logger.js (1 hunks)
  • scripts/tools/tools-object.js (2 hunks)
  • tests/build-pages.test.js (3 hunks)
🧰 Additional context used
🪛 eslint
scripts/tools/logger.js

[error] 13-13: Insert

(prettier/prettier)

scripts/tools/tools-object.js

[error] 11-11: Replace "./logger" with './logger'

(prettier/prettier)


[error] 111-111: Insert );⏎

(prettier/prettier)


[error] 117-117: Delete ,

(prettier/prettier)

tests/build-pages.test.js

[error] 26-27: Delete

(prettier/prettier)


[error] 44-45: Replace ⏎····[TEST_DIR,·NEW_TEST_DIR].forEach(dir with ····[TEST_DIR,·NEW_TEST_DIR].forEach((dir)

(prettier/prettier)


[error] 50-50: Delete ····

(prettier/prettier)


[error] 65-66: Delete

(prettier/prettier)

🔇 Additional comments (1)
scripts/tools/tools-object.js (1)

114-118: Good structured logging implementation

The error logging implementation provides good context with message, stack trace, and processing phase.

🧰 Tools
🪛 eslint

[error] 117-117: Delete ,

(prettier/prettier)

Comment on lines +66 to +68
if (fs.existsSync(NEW_TEST_DIR)) {
fs.rmSync(NEW_TEST_DIR, { recursive: true, force: true });
}
Copy link

@coderabbitai coderabbitai bot Dec 31, 2024

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Handle potential race condition in directory check

The existence check and directory creation are not atomic operations. Consider using mkdir with the recursive option to handle this more safely.

-    if (fs.existsSync(NEW_TEST_DIR)) {
-      fs.rmSync(NEW_TEST_DIR, { recursive: true, force: true });
-    }
+    try {
+      fs.mkdirSync(NEW_TEST_DIR, { recursive: true });
+    } catch (err) {
+      if (err.code !== 'EEXIST') {
+        throw err;
+      }
+      fs.rmSync(NEW_TEST_DIR, { recursive: true, force: true });
+      fs.mkdirSync(NEW_TEST_DIR, { recursive: true });
+    }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
if (fs.existsSync(NEW_TEST_DIR)) {
fs.rmSync(NEW_TEST_DIR, { recursive: true, force: true });
}
try {
fs.mkdirSync(NEW_TEST_DIR, { recursive: true });
} catch (err) {
if (err.code !== 'EEXIST') {
throw err;
}
fs.rmSync(NEW_TEST_DIR, { recursive: true, force: true });
fs.mkdirSync(NEW_TEST_DIR, { recursive: true });
}

Copy link

Choose a reason for hiding this comment

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

@sahitya-chandra, this might indicate that the test was closely tied to the original directory setup/cleanup sequence and is now encountering a mismatch in expectations after your refactor. If you want to keep the new approach (handling potential race conditions in mkdirSync), you can update the failing test so it aligns with the new logic—specifically around when the directory is expected to exist or be removed. If you’re pressed for time or the changes aren’t critical, you can revert the refactor to restore the test to a passing state. However, I recommend adjusting the test to handle the directory creation behavior consistently rather than reverting, because the improved approach makes your code more robust.

If you need more insight into the test failure, you could log or debug the point where it fails to confirm whether the directory removal or creation order is at play, or whether a race condition is causing a mismatch in the test’s timing. Once you confirm what the test is expecting, you can modify it accordingly to accommodate the new behavior.

Copy link
Author

Choose a reason for hiding this comment

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

the code suggestions that you gave above leads to failing the test.
what should I do ?? should I stick with my changes.

Copy link

Choose a reason for hiding this comment

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

@sahitya-chandra, it’s generally a good idea to keep the more robust directory-handling approach if possible. However, the test might be failing because it anticipates a very specific sequence of directory cleanup and creation. If you want to preserve the improved approach, you can update the test so that it expects directories to be created (or removed) in a non-racy way. For instance, ensure that the test logic accounts for the possibility that the directory may already exist when mkdirSync is called.

If you need to keep the test unchanged and the timing/race concerns are minimal in this context, then reverting to your previous simpler approach (checking if the directory exists and removing it if so) is also an option. It really depends on your priorities: a robust approach versus minimal test modifications. If the directory creation logic is important enough to risk a non-trivial refactor of the test, I recommend updating the test. Otherwise, revert the changes to restore the passing state.

@anshgoyalevil
Copy link
Member

That's some good progress @sahitya-chandra But looking at the scope of this issue, it seems like we would have to move it to the bounty program as there are a lot of places where we have to strategically add Winston Logger, and that would also require a lot of script tests to be changed

@sahitya-chandra
Copy link
Author

@anshgoyalevil sir what should I do now ??

@sahitya-chandra
Copy link
Author

That's some good progress @sahitya-chandra But looking at the scope of this issue, it seems like we would have to move it to the bounty program as there are a lot of places where we have to strategically add Winston Logger, and that would also require a lot of script tests to be changed

I think I can add winston to more places in the code in future

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.

Simplify error handling in build-dashboard.js
5 participants