[Bug] POST `/api/open/policy` Fails with `internal-error` Due to FSL Compilation Failure in `safeline-mgt`

What happened?

When sending a POST request to https://localhost:9443/api/open/policy to create a new policy, the API returns an internal-error response with the message "compiling failed: compiling FSL failed". The GET request to the same endpoint succeeds, indicating the API is accessible, but the POST operation fails. The error is logged in the safeline-mgt container, pointing to an issue with FSL (Filter Specification Language) compilation in the fvm service.

How we reproduce?

1. Set up the environment using the provided docker-compose.yml and .env files:
   • .env:

     1SAFELINE_DIR=./data/safeline
     2IMAGE_TAG=latest
     3MGT_PORT=9443
     4POSTGRES_PASSWORD=xxx
     5SUBNET_PREFIX=172.22.222
     6IMAGE_PREFIX=chaitin
     7ARCH_SUFFIX=
     8RELEASE=
     9REGION=-g

   • Relevant docker-compose.yml services: safeline-mgt, safeline-fvm, safeline-pg (full configuration provided in the original context).
2. Start the services:

   1docker-compose up -d

3. Verify the safeline-mgt service is running by sending a GET request:

   1curl -k https://localhost:9443/api/open/policy -H "X-SLCE-API-TOKEN: Your API Token"

   This should return a successful response.
4. Send a POST request to create a policy:

   1curl -k -X POST https://localhost:9443/api/open/policy \
   2-H "Content-Type: application/json" \
   3-H "X-SLCE-API-TOKEN: Your API Token" \
   4-d '{
   5    "name": "IPBlock",
   6    "is_enabled": true,
   7    "pattern": [
   8        [
   9            {
   10                "k": "src_ip",
   11                "op": "in",
   12                "v": [
   13                    "172.19.0.1"
   14                ],
   15                "sub_k": ""
   16            }
   17        ]
   18    ],
   19    "action": 1,
   20    "expire": 174854302,
   21    "log": true,
   22    "level": 0
   23}'

5. Observe the response and check the safeline-mgt container logs:

   1docker logs safeline-mgt

Expected behavior

The POST request to /api/open/policy should successfully create the policy and return a success response (e.g., HTTP 200 or 201 with a confirmation message, such as {"data": {...}, "msg": "success"}).

Error log

The safeline-mgt container logs show the following errors:

safeline-mgt  | 2025/05/29 10:42:18 [ERROR] fvm fvm/grpc_helper.go:76 FVM AppendFSL Close Error rpc error: code = Unknown desc = compiling failed: compiling FSL failed
safeline-mgt  | 2025/05/29 10:42:18 [ERROR] fvm fvm/grpc_helper.go:80 FVM AppendFSL Close Error rpc error: code = Unknown desc = compiling failed: compiling FSL failed
safeline-mgt  | 2025/05/29 10:42:18 [ERROR] fvm fvm/policy_rule.go:66 compile and push fsl error: rpc error: code = Unknown desc = compiling failed: compiling FSL failed
safeline-mgt  | 2025/05/29 10:42:18 [ERROR] api.policy gin@v1.10.0/context.go:185 create policy error: rules compile error, please check your params

The 'safeline-fvm' container logs show the following errors:

safeline-fvm  | time="2025-05-29T10:42:18Z" level=error msg="AppendFSL: compiling failed: compiling FSL failed"

API response:

1{
2    "data": {},
3    "msg": "internal-error"
4}

Use "op": "eq" for exact IP matching, while "in" is used to match IP group ids.

I updated the POST request to https://localhost:9443/api/open/policy by changing the operator from "in" to "eq" in the policy JSON, as shown below:

1curl -k -X POST https://localhost:9443/api/open/policy \
2-H "Content-Type: application/json" \
3-d '{
4    "name": "IPBlock",
5    "is_enabled": true,
6    "pattern": [
7        [
8            {
9                "k": "src_ip",
10                "op": "eq",
11                "v": [
12                    "172.19.0.1"
13                ],
14                "sub_k": ""
15            }
16        ]
17    ],
18    "action": 1,
19    "expire": 174854302,
20    "log": true,
21    "level": 0
22}'

The request now succeeds and returns the following response:

1{
2    "data": 16,
3    "err": null,
4    "msg": ""
5}

However, when I send a GET request to https://localhost:9443/api/open/policy to list all policies:

1curl -k https://localhost:9443/api/open/policy

Returns:

1{
2    "data": {
3        "data": [
4            {
5                "id": 2,
6                "created_at": "2025-04-25T15:35:38.108316Z",
7                "updated_at": "2025-04-25T15:35:38.452971Z",
8                "action": 0,
9                "name": "搜索引擎爬虫白名单",
10                "pattern": [
11                    [
12                        {
13                            "k": "src_ip",
14                            "op": "in",
15                            "v": [
16                                "2"
17                            ],
18                            "sub_k": ""
19                        }
20                    ]
21                ],
22                "is_enabled": true,
23                "builtin": true,
24                "log": false,
25                "expire": 0,
26                "level": 0,
27                "replay": false,
28                "cloud_id": 0,
29                "cloud_total": 0,
30                "black_rule": 0,
31                "white_rule": 0,
32                "auth_rule": 0,
33                "captcha_rule": 0,
34                "compatible": 0,
35                "auth_source_ids": null,
36                "negate": false,
37                "review": 0,
38                "auth_callback": "",
39                "tfa_enabled": false,
40                "req_count": 0,
41                "pass_count": 0
42            }
43        ],
44        "total": 1
45    },
46    "err": null,
47    "msg": ""
48}

The response does not include the newly created "IPBlock" rule. I expected the new policy to appear in the GET response, reflecting the successful POST.

It seems unlikely. Are you still having this issue?