API Workshop Bug: Special Characters In 'Keywords' Field

by Square 57 views
Iklan Headers

Hey everyone, let's dive into a particularly interesting bug we've encountered, focusing on how the API behaves when dealing with special characters in the 'Keywords' field. This is a backend issue, and the problem surfaces during workshop creation. The core of the issue is that when duplicate special characters are entered into the 'Keywords' field, it leads to the unexpected creation of an API workshop. This shouldn't be happening, and it's a critical bug that needs addressing. We'll go through the details, covering the environment, steps to reproduce, expected and actual results, and post-conditions. If you're interested in APIs and how they handle user input, or if you're part of the ita-social-projects team, this one's for you.

Environment and Build Details

First off, let's get our environment straight. This bug was observed on a Windows 10 machine, using Google Chrome Version 135.0.7049.85 (Official Build) (64-bit). For API interaction, we're relying on Postman, specifically version v11.63.1. It's always good to have a clear picture of where the issue happens. This is super important when trying to reproduce and fix the bug. The specific build where this bug was found is 51893b7. Knowing the build helps us pinpoint when the bug emerged, so we can track down the faulty code. Ensuring your environment matches these specifications will help replicate the bug on your end. If you're facing similar issues, knowing the tech stack is a must.

Preconditions for Reproduction

Before we start, we need to make sure a few things are in place. To reproduce this bug, the user must be logged in and authorized within Postman. This means you've authenticated successfully and have the necessary permissions to interact with the API. Think of it like having your keys to access a building. Without the right keys (authorization), you can't get in. When you are logged in and authorized, you can start interacting with the API and test the 'Keywords' field.

Steps to Reproduce the API Workshop Bug

Let's break down the exact steps to trigger this bug. These steps will guide you to reproduce the issue consistently. Here's how you can make it happen:

  1. Open Postman: Start by launching your Postman application. This is your main tool for interacting with the API.
  2. (Further steps to be added)

Follow these steps in sequence to reliably reproduce the unexpected workshop creation. It's essential to execute these steps precisely to see the bug in action. The specifics of the steps after opening Postman (Step 2) would involve crafting a request to create an API workshop, and, critically, including duplicate special characters in the 'Keywords' field. This is the key part where the bug manifests. Once the request is constructed correctly, the API will (incorrectly) process the input and create the workshop. The exact request body and the special characters used are important; we'll dig deeper into those later.

Understanding the Core Issue

When you create a workshop using the API, you usually send a request with information about the workshop. This includes things like a title, description, and keywords. The 'Keywords' field is designed to help categorize and search for workshops. But the way the API processes this field is where the problem lies. If you enter duplicate special characters, the API misinterprets this, and instead of rejecting the input or handling it correctly, it creates the workshop anyway. This is a sign of a problem within the validation or sanitization process of the API. This means there’s likely a flaw in how the system checks the input to make sure it’s valid and safe. The API should be able to handle these special characters, by either cleaning them up (sanitizing) or properly validating them before creating a new workshop. The unexpected workshop creation is a result of the API failing to do this.

Actual Result and Expected Result

Let's clarify the impact and desired outcome. The actual result is that a workshop gets created, even though the input in the 'Keywords' field is incorrect or contains duplicate special characters. It's like the API is ignoring the rules and creating something it shouldn't. We will provide screenshots and recorded videos of the issue, so you can see it in action. For the expected result, the API should either:

  • Reject the request: The request should be rejected because the 'Keywords' field contains invalid input.
  • Sanitize the input: The API should clean the input, removing or correcting the special characters before creating the workshop.
  • Return an error message: If the input is considered invalid, an appropriate error message should be returned to the user.

We will include screenshots or mock-ups to illustrate how the system should work, and we will cover the exact behavior of the system.

Postconditions and Further Actions

Now, what happens after you reproduce the bug? The postconditions outline the actions you should take. Let's say a workshop gets created unexpectedly. You will need to clean things up: Delete the item from the database to revert the unwanted changes. This is crucial to ensure the test environment is clean and ready for future tests. The SQL query for this looks like:

DELETE FROM table1 WHERE id=<item1_id>;

Replace <item1_id> with the actual ID of the workshop created by the bug. This ensures you’re only deleting the incorrect item. If you do not do this, it can mess up further testing. The postconditions also imply that you should log and document everything as you go. Include a clear description of what you did, the outcome, and any relevant details. This helps in reproducing the bug and finding the solution.

User Story and Test Case Links

We always link our work to user stories and test cases. This helps us keep track of the scope of our projects and also helps us make sure we are focusing on the user experience. For this particular bug, the user story and test case links are:

These links provide context and ensure we're aligning with broader project goals. User stories describe the feature from the end-user's perspective, and test cases define how we validate functionality. This helps you see where this bug fits into the bigger picture.

Labels for Tracking

For easy tracking and organization, we apply specific labels to this bug. These labels help in categorizing the issue. The labels to be added are:

  • "Bug": This is the most straightforward label, indicating the presence of a bug.
  • Priority ("pri: "): Specifies the priority of fixing the bug.
  • Severity ("severity:"): Indicates how severe the bug is, and its impact on the system.
  • Type ("UI", "Functional"): This specifies the type of the bug, in this case, it is "Functional".
  • "API": To signify it as a backend issue.

These labels are essential for managing and prioritizing the bug fixes. They also provide a quick overview of the bug’s characteristics, aiding in efficient project management.