This issue was partially fixed by #5920, as this PR demonstrated an example through a hardcoded string. The file to watch section still needs to be addressed, as that opens up a different way of technically updating the policy in that case.

Hi @ginayeh , I can work on this!

@shashank-priyadarshi -- thanks! Assigning this to you.

PS: please make sure that the issue is assigned to you while you are actively working on it. This would make sure we dont have multiple contributors working on the same issue

Hi @arvindbr8, I would like to contribute.

@v-sreejith -- Seems like this one is already assigned! Thanks for your interest.

@v-sreejith -- ping

@arvindbr8 Hi, can I work on this one if a file watcher example is still needed? I've gone through the existing tests referenced in the issue description and have got a grasp on what this one is about :)

@Kailun2047 Let us know what you have in mind for the example. Let's have a discussion before you get too deep into actual implementation. Thanks.

@easwars Sure. I'm thinking about extending the current example a bit. Concretely:

• add an example JSON policy file to hold policy content that's meant to be identical to the hardcoded one but with intentional typos in both header keys
• for server, modify server/main.go to accept an optional flag that starts the server using file watcher authz interceptors (unary & streaming) that watches the file mentioned above
• for client, keep it as is

When the example is run, the client will first end up with unexpected PermissionDenied error when requesting with authorized role. Instruct our users to then manually fix the JSON policy file while keep the server running, and start the client again to get the expected responses. Maybe we can also have GRPC_GO_LOG_SEVERITY_LEVEL set when running the example server, so that the reload status of the policy can be spotted.

@Kailun2047 : Sounds like a good plan. Looking forward to reviewing your PR.

@easwars Just put up #7226 for this. Please take a look when you get time. Thanks.