V6 Bug - unable to delete subscribed lists with %20 in URL field

I have added some subscribed lists with spaces in the name which are encoded to %20 in the URL path. After adding these they cannot be deleted. The GUI displays the toast notification and says that deletion is successful but the list remains. Have narrowed test case down to adding a list URL as just %20 and it can't be deleted.

I don't have v5 to test with to see if this is a regression but I suspect it is, as it would surely have been detected previously.

I can confirm this behavior. Entries with XYZ%20.com can't be deleted.

2024-01-08 13:36:48.304 [472116/T472166] DEBUG_API: Requested API URI: 10.0.1.202 -> POST /api/lists:batchDelete ? (null) (Content-Type application/x-www-form-urlencoded; charset=UTF-8)
2024-01-08 13:36:48.304 [472116/T472166] DEBUG_API: Received payload with size: 25
2024-01-08 13:36:48.305 [472116/T472166] DEBUG_API: Processing POST /api/lists:batchDelete in /api/lists:batchDelete
2024-01-08 13:36:48.306 [472116/T472166] DEBUG_API: SQL: INSERT INTO deltable (item) VALUES (:item);
2024-01-08 13:36:48.306 [472116/T472166] DEBUG_API:      :item = "sdjfsdk+.com"
2024-01-08 13:36:48.559 [472116/T472166] DEBUG_API: Done

Response is a 404 not found.

id  address                                                                                  enabled  date_added  date_modified  comment                                 date_updated  number   invalid_domains  status  abp_entries  type
--  ---------------------------------------------------------------------------------------  -------  ----------  -------------  --------------------------------------  ------------  -------  ---------------  ------  -----------  ----


24  sdjfsdk%20.com                                                                           1        1704717327  1704717327     (null)                                  (null)        0        0                0       0            0   

@DL6ER Could be a regression of the batchDelete PR or a encoding issue (see %20 turned into + )

Thanks for the report, the fix is very simple:

confirmed fixed, thanks!