elise-ng / comp4111_project Goto Github PK

When multiple statement is passed to the transaction and committed, it shall rollback/not make any change if one of the statements causes error.

However, based on the testing, I have chained two statements ( first one being right and last being wrong). Committing results in 200 SC_OK and the first SQL statement is executed.

{ "Transaction": {{transaction1}}, "Book": 50, "Action": "loan" }
{ "Transaction": {{transaction1}}, "Book": 999999, "Action": "return" }

Transaction in the db: (Obviously one with id=999999 is wrong)

Commit success (somehow)

Database does make valid book (id=50) being loaned

Collection Link: https://www.getpostman.com/collections/60fd4e59edd2e444ed04

In transaction behavior, after the timeout, the transaction does not exist anymore, it is more like auto-rollbacked, and not supposed to run any statement. However, the server only checks the timeout (2 mins in your case) when committing the transaction.

Therefore, I can still push an action after 5 mins.

Steps to reproduce the issue

1. Log in first.
2. Add the follwing books:

   {
       "Title": "Alice in Wonderland",
       "Author": "Lewis Carroll",
       "Publisher": "Macmillan Publishers",
       "Year": 1865
   }

   {
       "Title": "Alice",
       "Author": "Lewis",
       "Publisher": "Mac",
       "Year": 2020
   }

   {
       "Title": "SINoALICE",
       "Author": "SQUARE",
       "Publisher": "ENIX",
       "Year": 2017
   }

3. Look up book information with GET /BookManagementService/books?order=desc&token=${token}. There should be no corresponding valid SQL query.

What's the expected result?

Response like 400 Bad Request to notify the user that something is not right.

What's the actual result?

200 OK with the following payload is returned.

{
    "Results":[
        {
            "Title":"Alice in Wonderland",
            "Author":"Lewis Carroll",
            "Publisher":"Macmillan Publishers",
            "Year":1865,
            "Available":true
        },
        {
            "Title":"Alice",
            "Author":"Lewis",
            "Publisher":"Mac",
            "Year":2020,
            "Available":true
        },
        {
            "Title":"SINoALICE",
            "Author":"SQUARE",
            "Publisher":"ENIX",
            "Year":2017,
            "Available":true
        }
    ],
    "FoundBooks":3
}

When no books record is found for a given query, instead of returning 204 according to the specification, it returns 200 instead.

Steps to reproduce the issue (1)

• Attempt to log in with GET /BookManagementService/login (it should be POST) and payload

  {
      "Username": "user00001",
      "Password": "pass00001"
  }

What's the expected result? (1)

Ideally 405 Method Not Allowed.

What's the actual result? (1)

No response is received.

Steps to reproduce the issue (2)

1. Log in first.
2. Attempt to log out with POST /BookManagementService/logout?token=${token} (it should be GET).

What's the expected result? (2)

Ideally 405 Method Not Allowed.

What's the actual result? (2)

200 OK is received. The corresponding user apparently logs out since subsequent GET /BookManagementService/logout?token=${token} returns 400 Bad Request.

Steps to reproduce the issue (3)

1. Log in first.
2. Request a transaction ID.
3. Commit a transaction with GET /BookManagementService/transaction?token=${token} (it should be POST) and payload

   {
       "Transaction": ${transaction},
       "Operation": "commit"
   }

What's the expected result? (3)

Ideally 405 Method Not Allowed.

What's the actual result? (3)

No response is received.

Steps to reproduce the issue (4)

1. Log in first.
2. Add a book.
3. Request a transaction ID.
4. Attempt to loan the book with GET BookManagementService/transaction?token=${token} (it should be PUT) and payload

   {
       "Transaction": ${transaction},
       "Book": ${id},
       "Action": "loan"
   }

What's the expected result? (4)

Ideally 405 Method Not Allowed.

What's the actual result? (4)

No response is received.

Actually when sending a false transaction, it is always considered as right somehow. A False statement like this:

{ "Transaction": {{transaction1}}, "Book": 999999, "Action": "loan" }

returns 200 SC_OK upon commit. This is actually similiar to #13, in which this issue might actually be the cause of it: my guess is that since both statements in #13 are misidentified as both being correct, the rollback function (if any) doesn't even trigger in the first place.

However, I still decide to create this new issue, because wrong statement identified as right is one thing, unable to rollback invalid change is another thing. If I can't even access the rollback functionality and test it, one can consider that it fails the specification separately.

collection link: https://www.getpostman.com/collections/79ee6de1360b38f0789b

#Edit: Better Spacing
#Edit2: More Image to explain

put action, which is successful

Commit action right after put action, which also is successful

if the validation was valid, regardless of the implementation, it would return at least one 400 bad request in either one of the two responses

Steps to reproduce the issue

1. Log in first.
2. Add the follwing books:

   {
       "Title": "Alice in Wonderland",
       "Author": "Lewis Carroll",
       "Publisher": "Macmillan Publishers",
       "Year": 1865
   }

   {
       "Title": "Alice",
       "Author": "Lewis",
       "Publisher": "Mac",
       "Year": 2020
   }

   {
       "Title": "SINoALICE",
       "Author": "SQUARE",
       "Publisher": "ENIX",
       "Year": 2017
   }

3. Look up book information with GET /BookManagementService/books?sortby=ids&token=${token} or GET /BookManagementService/books?sortby=ids&order=desc&token=${token}. Note that ids is invalid.

What's the expected result?

Response like 400 Bad Request to notify the user that something is not right.

What's the actual result?

Both GET /BookManagementService/books?sortby=ids&token=${token} and GET /BookManagementService/books?sortby=ids&order=desc&token=${token} give 200 OK with the following payload:

{
    "Results":[
        {
            "Title":"Alice in Wonderland",
            "Author":"Lewis Carroll",
            "Publisher":"Macmillan Publishers",
            "Year":1865,
            "Available":true
        },
        {
            "Title":"Alice",
            "Author":"Lewis",
            "Publisher":"Mac",
            "Year":2020,
            "Available":true
        },
        {
            "Title":"SINoALICE",
            "Author":"SQUARE",
            "Publisher":"ENIX",
            "Year":2017,
            "Available":true
        }
    ],
    "FoundBooks":3
}

Description

Prepared operation is done even the transaction is canceled.

How to reproduce

1. Login as usual
2. Add the following book

{
        "Title": "Book 1",
        "Author": "First Guy",
        "Publisher": "First Inc.",
        "Year": 2020
}

3. Request a Transaction ID, the sample result is as follow:

{
    "Transaction": 219
}

4. Prepare a transaction operation as follow:

{
	"Transaction" : 219,
	"Book" : 1,
	"Action": "loan"
}

5. Cancel the transaction with id 219

{
	"Transaction" : 219,
	"Operation" : "cancel"
}

6. Loan the book with id 1

Expected results

The server returns 200 OK

What actually happens

The server returns 400 Bad Request

Describe the bug
Server return no response updating non-numeric ID book status.

To Reproduce

1. Login as usual
2. Update book with a non-numeric ID (e.g. hi) with the payload below.
   PUT /BookManagementService/books/hi?token={{token}}

{
	"Available" : true
}

Expected behaviour
400 Bad Request or 404 Not Found or other custom behaviour that does not crash the server.

What actually happens
The server does not produce a response with exception thrown in the console

api_1  | Exception in thread "Thread-3" java.lang.NumberFormatException: For input string: "hi"
api_1  | 	at java.base/java.lang.NumberFormatException.forInputString(Unknown Source)
api_1  | 	at java.base/java.lang.Integer.parseInt(Unknown Source)
api_1  | 	at java.base/java.lang.Integer.parseInt(Unknown Source)
api_1  | 	at BooksRequestHandler.handleAvailability(BooksRequestHandler.java:180)
api_1  | 	at BooksRequestHandler.lambda$handle$0(BooksRequestHandler.java:59)
api_1  | 	at java.base/java.lang.Thread.run(Unknown Source)

Describe the bug
% character is not escaped in LIKE statements in book searching criteria.

To Reproduce

1. Login as usual
2. Add the following book

{
            "Title": "Book 25!",
            "Author": "Author",
            "Publisher": "Publisher",
            "Year": "2028"
}

3. Search book containing title specified below
   GET localhost:8080/BookManagementService/books?token={{token}}&title=%25

Expected behavior
204 No Content

What actually happens
200 OK with the book returned

{
    "Results": [
        {
            "Title": "Book 25!",
            "Author": "Author",
            "Publisher": "Publisher",
            "Year": 2028,
            "Available": true
        }
    ],
    "FoundBooks": 1
}

similiar issue for #11, but I'll consider it as a new issue since get book record and add book are two different features. Will let @comp4111ta to decide whether it counts as the same issue or not

correct url for searching book should be /BookManagementService/books?token=. However, it's also possible to use /BookManagementService/books/some_id?token= as long as it is a POST request. This wrong url should only be used for loaning.

correct url for searching book should be /BookManagementService/books?token=. However, it's also possible to use /BookManagementService/books/30?token= as long as it is a GET request. This wrong url should only be used for loaning.

orderby seems to not working properly. Sorting based on title and order based on desc, but doesn't return the expected output and instead just directly showed the books in their database order.

*Edit: Wrong request URL in the image. This one's fixed

1. Log in first.
2. Add a book with POST /BookManagementService/books?token=${token} and payload being

   {
       "Title": "Alice",
       "Author": "Lewis",
       "Publisher": "Mac"
   }

   or

   {
       "Title": "Alice",
       "Author": "Lewis",
       "Publisher": "Mac",
       "Year": null
   }

What's the expected result?

400 Bad Request. There are no problems with returning 400 Bad Request if the title/author/publisher is missing/null though.

What's the actual result?

No response is received.

Steps to reproduce the issue

1. Log in first.
2. Add a book.
3. Request with PUT /BookManagementService/books/${id}?token=${token} and payload being {}.

What's the expected result?

400 Bad Request. There is no problem with returning 400 Bad Request if the payload is of length zero though.

What's the actual result?

200 OK.

when a duplicate book is added, while it correctly returns the right status code as well as not adding the book into the database, the returned response header is wrong: Instead of "Duplicate Record", it uses "Location" which should only be used when successfully adding a book.

Even through some of these seems to be intended, but these behavior seems to be weird in my opinion (needs TA to evaluate whether it's an issue or not):

Could not receive any response if year is supplied with empty string:

Empty String with publisher/author

response return 400 when either author or publisher is supplied with empty string. This behavior is intentional since the case is considered as invalid. However, one can argue that author/publisher explicitly stated as "" is valid since it's possible for unknown author/publisher.

Year accepting weird input

The way year is treated through parseInt allows weird input to be accepted: In the most extreme case it will allow negative float number to be accepted which will be rounded-up to 0 inside the database.

In transaction behaviors, when you start a transaction, even you do not run any statement, you can still commit. But the server returns 400 for committing an empty transaction.

You can try with the test case below.
https://trial-howard-20200221.s3.ap-east-1.amazonaws.com/Empty+Transaction+400+.jmx

Describe the bug
Requests with invalid paths successfully update the database. To be particular, the subpaths between books and id (exclusive) are ignored.

To Reproduce

1. Login as usual
2. Add a book. The book id should be 1 for first run.

{
	"Title": "Delete me yo!",
	"Author": "Bug Hunter",
	"Publisher": "Bug Bounty Inc.",
	"Year": 2020
}

3. Send an illegal request as below
   DELETE /BookManagementService/books/hi/1?token={{token}}

Expected behavior
400 Bad Request or 404 Not Found or other reasonable custom behavior
The book remains in the database, which can be verified with a lookup quest.
GET /BookManagementService/books?id=1&token={{token}}

Response of lookup request: 200 OK

{
    "FoundBooks": 1,
    "Results": [
        {
            "Title": "Delete me yo!",
            "Author": "Bug Hunter",
            "Publisher": "Bug Bounty Inc.",
            "Year": 2020
        }
    ]
}

What actually happens
200 OK
The book is indeed deleted, which can be verified with a lookup quest.
GET /BookManagementService/books?id=1&token={{token}}

Response of lookup request: 204 No content