stange behaviour when using `body_filter_by_lua_file` together with `content_by_lua_block`

access_by_lua_block {
    if ngx.var.test then -- for reproducing the behaviour
        ngx.exit(ngx.HTTP_FORBIDDEN)
    end
}
content_by_lua_file './echo.lua';
body_filter_by_lua_block{
    ngx.arg[1] = string.upper(ngx.arg[1])
}

-- ./echo.lua which content is not really matter
for k, v in pairs((ngx.req.get_headers())) do
  ngx.say("<p>",k, ":", v,"</p>");
end

It's works fine as long as no "test" parameter is sent.
And after that, it's OK to keep responsing with capitallized 403 page to "test" request.
But it fails to response to normal requsest, with logs saying:

failed to run body_filter_by_lua*: ./echo.lua:1: API disabled in the context of body_filter_by_lua*

As the msg suggests, I believe that body_filter_by_lua* is not supposed to use together with content_by_lua*, but it didn't shows up until first forbidden request.

envrioment:

windows 10
nginx version: openresty/1.17.8.2
built by gcc 7.3.0 (Rev1, Built by MSYS2 project)
built with OpenSSL 1.1.1g 21 Apr 2020
TLS SNI support enabled
configure arguments: --prefix=. --with-cc-opt='-O2 -DFD_SETSIZE=1024' --add-module=../ngx_devel_kit-0.3.1 --add-module=../echo-nginx-module-0.62 --add-module=../xss-nginx-module-0.06 --add-module=../ngx_coolkit-0.2 --add-module=../set-misc-nginx-module-0.32 --add-module=../form-input-nginx-module-0.12 --add-module=../encrypted-session-nginx-module-0.08 --add-module=../srcache-nginx-module-0.32 --add-module=../ngx_lua-0.10.17 --add-module=../ngx_lua_upstream-0.07 --add-module=../headers-more-nginx-module-0.33 --add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.19 --add-module=../redis2-nginx-module-0.15 --add-module=../redis-nginx-module-0.3.7 --add-module=../ngx_stream_lua-0.0.8 --with-cc=gcc --with-ipv6 --sbin-path=nginx.exe --with-pcre-jit --with-ipv6 --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_v2_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_stub_status_module --with-http_realip_module --with-http_addition_module --with-http_auth_request_module --with-http_secure_link_module --with-http_random_index_module --with-http_gzip_static_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-select_module --with-pcre=/home/agentzh/work/openresty-1.17.8.2/objs/lib/pcre-8.44 --with-zlib=/home/agentzh/work/openresty-1.17.8.2/objs/lib/zlib-1.2.11 --with-openssl=/home/agentzh/work/openresty-1.17.8.2/objs/lib/openssl-1.1.1g --with-openssl-opt=-g --with-pcre-opt=-g --with-zlib-opt=-g --with-stream --with-stream_ssl_preread_module --with-http_ssl_module

Reproduce the issue with the shown nginx configuration and ./echo.lua, using both ordinary requests and requests with the test parameter. Start by tracing the interaction between access_by_lua_block, content_by_lua_file, and body_filter_by_lua_block around the 403 response. Done means subsequent normal requests no longer report that ./echo.lua is being run in the body-filter context with the API disabled.