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

Missing content encoding for attachments in JSON reports #2260

Closed
badeball opened this issue Mar 19, 2023 · 6 comments · Fixed by #2261
Closed

Missing content encoding for attachments in JSON reports #2260

badeball opened this issue Mar 19, 2023 · 6 comments · Fixed by #2261
Labels
🐛 bug Defect / Bug 🙏 help wanted Help wanted - not prioritized by core team ✅ accepted The core team has agreed that it is a good idea to fix this

Comments

@badeball
Copy link
Member

badeball commented Mar 19, 2023

👓 What did you see?

Consider the following code adding two string attachments:

Given("a step", function () {
  const myString = "foobar"
  this.attach(myString, "text/plain");
  this.attach(Buffer.from(myString).toString("base64"), "base64:text/plain");
});

This will create two envelopes (messages) with different contentEncoding (IDENTITY and BASE64 respectively). However, this information (content encoding) is lost in the JSON report and the original data cannot be reproduced with certainty.

Below is the JSON report:

[
  {
    "description": "",
    "elements": [
      {
        "description": "",
        "id": "a-feature;an-example",
        "keyword": "Example",
        "line": 2,
        "name": "an example",
        "steps": [
          {
            "arguments": [],
            "keyword": "Given ",
            "line": 3,
            "name": "a step",
            "match": {
              "location": "features/definitions.js:3"
            },
            "result": {
              "status": "passed",
              "duration": 492577
            },
            "embeddings": [
              {
                "data": "foobar",
                "mime_type": "text/plain"
              },
              {
                "data": "Zm9vYmFy",
                "mime_type": "text/plain"
              }
            ]
          }
        ],
        "tags": [],
        "type": "scenario"
      }
    ],
    "id": "a-feature",
    "line": 1,
    "keyword": "Feature",
    "name": "a feature",
    "tags": [],
    "uri": "features/foo.feature"
  }
]

✅ What did you expect to see?

I guess for JSON reports to either only ever contain base64 encoded data or for content encoding to be propagated to the report.

📦 Which tool/library version are you using?

  • cucumber-js: 9.0.1

🔬 How could we reproduce it?

Steps to reproduce the behavior:

  1. git clone https://github.com/badeball/cucumber-reproducible-issues.git
  2. cd cucumber-reproducible-issues/string-attachment-ambiguity
  3. npm install
  4. npx cucumber-js
@badeball badeball added the 🐛 bug Defect / Bug label Mar 19, 2023
@badeball
Copy link
Member Author

badeball commented Mar 20, 2023

For reference, cucumber-json-formatter will take attachments with IDENTITY encoding and base64-encode them before outputting a JSON report, thus generating a different one, where both embeddings are identical.

@davidjgoss
Copy link
Contributor

For reference, cucumber-json-formatter will take attachments with IDENTITY encoding and base64-encode them before outputting a JSON report, thus generating a different one, where both embeddings are identical.

Okay, that seems like the canonical behaviour we should follow then.

@davidjgoss davidjgoss added 🙏 help wanted Help wanted - not prioritized by core team ✅ accepted The core team has agreed that it is a good idea to fix this labels Mar 20, 2023
@badeball
Copy link
Member Author

Excellent, I'll attempt to create a PR 👍

@badeball
Copy link
Member Author

badeball commented Mar 20, 2023

This would however mean that string attachments, as they were attached pre #1552, would suddenly appear as base64-encoded data in JSON reports. Thus making this seem like a breaking change. Is that relevant in any way?

@davidjgoss
Copy link
Contributor

Yep, I think it's a breaking change. We have the end of life for Node.js 14 coming up at the end of April so we could do a major release then with both in.

@davidjgoss
Copy link
Contributor

Released in https://github.com/cucumber/cucumber-js/releases/tag/v10.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Defect / Bug 🙏 help wanted Help wanted - not prioritized by core team ✅ accepted The core team has agreed that it is a good idea to fix this
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants