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

Stop sending full defences on low levels #844

Merged
merged 43 commits into from
Mar 12, 2024

Conversation

pmarsh-scottlogic
Copy link
Contributor

@pmarsh-scottlogic pmarsh-scottlogic commented Feb 23, 2024

Description

Level 1 and and 2 don't have defences. So they don't need defences stored in the backend session, nor do they need to be passed to the frontend. So I've got rid of 'em

Notes

  • For level 1 and 2, we store undefined in the defences part of the session rather that a big defences object.
  • While I was there, I made the endpoint validation a bit more stringent

Checklist

Have you done the following?

  • Linked the relevant Issue - no issue
  • Added tests
  • Ensured the workflow steps are passing

@pmarsh-scottlogic pmarsh-scottlogic mentioned this pull request Feb 23, 2024
3 tasks
@pmarsh-scottlogic pmarsh-scottlogic self-assigned this Feb 23, 2024
@pmarsh-scottlogic pmarsh-scottlogic marked this pull request as ready for review February 23, 2024 17:23
@pmarsh-scottlogic pmarsh-scottlogic changed the title Stop sending full defences on low leevels Stop sending full defences on low levels Feb 26, 2024
Copy link
Member

@chriswilty chriswilty left a comment

Choose a reason for hiding this comment

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

Not sure if I'm reading it correctly, but looks like there's a logical error here for LEVEL_3 defences. If your test coverage was better, those would be able to tell me if my thinking was correct or not 😉

backend/src/controller/defenceController.ts Outdated Show resolved Hide resolved
backend/src/server.ts Outdated Show resolved Hide resolved
backend/src/controller/defenceController.ts Outdated Show resolved Hide resolved
@pmarsh-scottlogic
Copy link
Contributor Author

pmarsh-scottlogic commented Feb 29, 2024

Right. I've done a bunch more stuff

  • removed the weird type guarding I was doing before, and made it so that levels 3 and sandbox can be configured.
  • Revamped the validation across the defenceController endpoints because it was a bit naff. (this could've been a separate ticket, or at least PR. sorry)
  • Altered handleResetSingleDefence and related code (backend and frontend).
    • renamed to handleResetDefenceConfigItem
    • renamed the stuff that just said configId to configItemId
    • Now takes a level parameter to be in line with the other endpoints, even if it's technically not necessary. I think consistency is more important. Don't know if that will be a popular decision.
  • adds full unit testing for defenceController
  • adds integration testing for defenceController, which make sure that the right levels can and can't be configured. The reason these are integration tests and not unit tests is because a level's configurability is determined by whether its defences property is initially undefined or not.

Copy link
Member

@chriswilty chriswilty left a comment

Choose a reason for hiding this comment

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

Lovely work, lots going on here! All those defence controller unit tests made my eyes glaze over 😅

backend/src/controller/defenceController.ts Show resolved Hide resolved
backend/src/controller/defenceController.ts Outdated Show resolved Hide resolved
backend/src/controller/defenceController.ts Outdated Show resolved Hide resolved
backend/src/controller/defenceController.ts Outdated Show resolved Hide resolved
backend/src/controller/defenceController.ts Outdated Show resolved Hide resolved
backend/src/controller/defenceController.ts Outdated Show resolved Hide resolved
backend/test/integration/defenceController.test.ts Outdated Show resolved Hide resolved
backend/test/integration/defenceController.test.ts Outdated Show resolved Hide resolved
backend/test/integration/defenceController.test.ts Outdated Show resolved Hide resolved
@pmarsh-scottlogic
Copy link
Contributor Author

I've restructured the tests in integration/defenceController.test. They now use the neat test.each() syntax that I saw in your other PR, and they're structured by controller method. The tests themselves haven't seen any change, apart from configure defence and reset config item, which now make sure that an error response is returned if on levels 1, 2 or 3.

Copy link
Member

@chriswilty chriswilty left a comment

Choose a reason for hiding this comment

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

A few minor thoughts, but this looks good now 👍

backend/test/unit/controller/levelController.test.ts Outdated Show resolved Hide resolved
backend/test/unit/controller/startController.test.ts Outdated Show resolved Hide resolved
@@ -240,14 +241,15 @@ async function handleChatToGPT(req: OpenAiChatRequest, res: Response) {
? req.session.chatModel
: defaultChatModel;

const defences =
Copy link
Member

Choose a reason for hiding this comment

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

I'm wondering why we want to define defences here (other than the system role) for levels 1 and 2, which leads me to wonder why handleChatWithoutDefenceDetection needs to receive the defences at all...

If you follow the passing of defences through handleChatWithoutDefenceDetection and beyond, you end up at handleAskQuestionFunction in src/openai.ts, which simply checks if the Q&A LLM defence is active. If we don't have any defences, then surely we can assume it's not active. Plus, it feels overly complex to be passing all the defences through so many calls, when all we need is the QA_LLM defence.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

what do you suggest? pass undefined through the calls instead? Make new methods for the whole call chain for getting a response without defences? I vote the former

Copy link
Member

Choose a reason for hiding this comment

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

I suggest we don't pass defences into either handleChat function. The entire function call chain is self-contained, i.e. all functions are only invoked within this single call chain, so why not simply look up the defences from local storage in handleAskQuestionFunction? The currentLevel is passed all the way down so it's a trivial lookup. No need to pass defences down at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The answer is: to get something from the session, we need access to the req object

Copy link
Member

Choose a reason for hiding this comment

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

Of course, silly me! As discussed, let's try passing just the Q&A LLM defence down the call chain, but also have it optional so we don't need it for levels 1 and 2.

backend/src/controller/defenceController.ts Show resolved Hide resolved
frontend/src/service/defenceService.ts Show resolved Hide resolved
frontend/src/service/defenceService.ts Outdated Show resolved Hide resolved
Copy link
Member

@chriswilty chriswilty left a comment

Choose a reason for hiding this comment

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

Yep looks good, just the question of what to do with the defences param, which I've answered above.

Copy link
Member

@chriswilty chriswilty left a comment

Choose a reason for hiding this comment

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

Looking good, minor suggestions only.

backend/src/models/defence.ts Show resolved Hide resolved
backend/src/models/defence.ts Outdated Show resolved Hide resolved
backend/src/openai.ts Show resolved Hide resolved
Copy link
Member

@chriswilty chriswilty left a comment

Choose a reason for hiding this comment

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

Lovely ⚡

@pmarsh-scottlogic pmarsh-scottlogic merged commit 255f559 into dev Mar 12, 2024
4 checks passed
@pmarsh-scottlogic pmarsh-scottlogic deleted the stop-sending-full-defences-on-low-leevels branch March 12, 2024 15:04
chriswilty pushed a commit that referenced this pull request Apr 8, 2024
* defences undefined for levels 1 and 2

* fixes tests

* propoerly undefines defences on level 1 and 2

* moves variable declarations to destructureing

* missed one

* undo error swallow

* remove bad type guards

* improve validation for configureDefence

* last bit of validation

* update tests for handleConfigureDefence

* new folder for defence controller  unit tests and wrote first handleDefencecActivation test

* adds test for defence activation

* adds tests for defence deactivation

* moves tests all back into one file again

* adds tests for handleResetSingleDefence

* improve validation on handleGetDefenceStatus

* removes extraneous stuff from test objects

* adds tests to make sure defences aren't chngeable for level 1

* add loop to test levels 1 and 2 with same code

* adds remaining tests for defence controller integration

* handleResetSingleDefence takes level parameter now

* adds level to frontend call to reset defence config item. Types all the prop drillings properly

* some renamings and fill in gaps in tests

* adds another missing test

* tweaks

* fix test suite

* replace defence search with defences.some and replace cuurrentDefences === undefined check with not currentDefences

* change defenceId for generic falsy check

* improve guards for level and config

* improve guards for level and config

* correct test for configuring a config item

* updates error message when not allowed to activate or modify defences

* rescturecure defence controller integration tests

* change other tests to use test.each rather than foreach

* uses isValidLevel

* improve validateFilterConfig

* just pass qa defence rather than all defences

* fix tests

* uses type intersection to define QaLlmDefence

* only gedDefencesFrDTOs if it is defined
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.

2 participants