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

Arguments of Bedrock's client.create_guardrail not working as expected #3212

Closed
pd2871 opened this issue Jun 26, 2024 · 2 comments
Closed

Arguments of Bedrock's client.create_guardrail not working as expected #3212

pd2871 opened this issue Jun 26, 2024 · 2 comments
Assignees
Labels
service-api This issue is caused by the service API, not the SDK implementation.

Comments

@pd2871
Copy link

pd2871 commented Jun 26, 2024

Describe the bug

According to AWS documentation, some of the fields are not required compulsorily in client.create_guardrail
wordPolicyConfig
topicPolicyConfig
...
...

So, the main problem I am facing is when creating a guardrail using boto3, these fields are needed compulsorily.

ParamValidationError: Parameter validation failed:
Invalid length for parameter wordPolicyConfig.wordsConfig[0].text, value: 0, valid min length: 1

I do not want LLM to restrict on any specific word after creating guardrails using boto3 but boto3 keeps on throwing error to add atleast 1 word?

So, I hope boto3 team makes these fields Optional instead of COMPULSORY.

Expected Behavior

I expected that if I pass wordPolicyConfig=None while using client.create_guardrail, it should work fine.

client.create_guardrail(wordPolicyConfig=None)

It is expected to not throw any error

Current Behavior

If wordPolicyConfig=None is passed with client.create_guardrail, it throws error.

ParamValidationError: Parameter validation failed:
Invalid length for parameter wordPolicyConfig.wordsConfig[0].text, value: 0, valid min length: 1

Reproduction Steps

Some of those fields should be made Optional instead of Compulsory based on AWS Guardrails API documentation.

Possible Solution

Some of those fields should be made Optional instead of Compulsory based on AWS Guardrails API documentation.

Additional Information/Context

No response

SDK version used

1.34.105

Environment details (OS name and version, etc.)

Windows 10

@pd2871 pd2871 added bug This issue is a confirmed bug. needs-triage This issue or PR still needs to be triaged. labels Jun 26, 2024
@pd2871 pd2871 changed the title Arguments of client.create_guardrail not working as expected Arguments of Bedrock's client.create_guardrail not working as expected Jun 27, 2024
@tim-finnigan tim-finnigan self-assigned this Jun 27, 2024
@tim-finnigan tim-finnigan added the investigating This issue is being investigated and/or work is in progress to resolve the issue. label Jun 27, 2024
@tim-finnigan
Copy link
Contributor

Thanks for reaching out. If a parameter is optional and you do not want to use it, then you should just not include it in your command. Otherwise it is expected that the command would fail with a ParamValidationError here, because you are passing a None type. When I try that I get the error:

botocore.exceptions.ParamValidationError: Parameter validation failed:
Invalid type for parameter wordPolicyConfig, value: None, type: <class 'NoneType'>, valid types: <class 'dict'>

What you're actually doing is probably:

 'wordPolicyConfig':{
        'wordsConfig': [
            {
                'text': ''
            },
        ],
    },

I get the error you referenced when attempting to use that configuration. The API is expecting a value for text here.

Also the Boto3 create_guardail command involves a call to the underlying Amazon Bedrock CreateGuardrail API. Therefore the Boto3 team here cannot modify the underlying behavior here. If you'd like someone to reach out to the Bedrock team on your behalf, please create an issue in our cross-SDK repository (https://github.com/aws/aws-sdk/issues) outlining your request.

@tim-finnigan tim-finnigan closed this as not planned Won't fix, can't repro, duplicate, stale Jun 27, 2024
@tim-finnigan tim-finnigan added service-api This issue is caused by the service API, not the SDK implementation. and removed bug This issue is a confirmed bug. investigating This issue is being investigated and/or work is in progress to resolve the issue. needs-triage This issue or PR still needs to be triaged. labels Jun 27, 2024
Copy link

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
service-api This issue is caused by the service API, not the SDK implementation.
Projects
None yet
Development

No branches or pull requests

2 participants