chore: make ci happy again

This commit is contained in:
某文 2023-05-16 20:57:57 +08:00
parent 7d7c069257
commit a2aa6b4666
3 changed files with 23 additions and 28 deletions

View File

@ -1284,19 +1284,17 @@ t_inconsistent_webhook_request_timeouts(Config) ->
<<"resource_opts">> => #{<<"request_timeout">> => <<"2s">>} <<"resource_opts">> => #{<<"request_timeout">> => <<"2s">>}
} }
), ),
?assertMatch( {ok, 201, #{
{ok, 201, #{ <<"request_timeout">> := <<"1s">>,
%% note: same value on both fields <<"resource_opts">> := ResourceOpts
<<"request_timeout">> := <<"2s">>, }} =
<<"resource_opts">> := #{<<"request_timeout">> := <<"2s">>}
}},
request_json( request_json(
post, post,
uri(["bridges"]), uri(["bridges"]),
BadBridgeParams, BadBridgeParams,
Config Config
) ),
), ?assertNot(maps:is_key(<<"request_timeout">>, ResourceOpts)),
ok. ok.
%% %%

View File

@ -59,27 +59,21 @@ webhook_config_test() ->
}, },
check(Conf2) check(Conf2)
), ),
#{
%% the converter should pick the greater of the two <<"bridges">> := #{
%% request_timeouts and place them in the root and inside <<"webhook">> := #{
%% resource_opts. <<"the_name">> :=
?assertMatch( #{
#{ <<"method">> := get,
<<"bridges">> := #{ <<"request_timeout">> := RequestTime,
<<"webhook">> := #{ <<"resource_opts">> := ResourceOpts,
<<"the_name">> := <<"body">> := <<"${payload}">>
#{ }
<<"method">> := get,
<<"request_timeout">> := 60_000,
<<"resource_opts">> := #{<<"request_timeout">> := 60_000},
<<"body">> := <<"${payload}">>
}
}
} }
}, }
check(Conf3) } = check(Conf3),
), ?assertEqual(60_000, RequestTime),
?assertNot(maps:is_key(<<"requst_timeout">>, ResourceOpts)),
ok. ok.
up(#{<<"bridges">> := Bridges0} = Conf0) -> up(#{<<"bridges">> := Bridges0} = Conf0) ->

View File

@ -0,0 +1,3 @@
We deprecated the request_timeout in resource_option of the webhook to keep it consistent with the http request_timeout of the webhook.
From now on, when configuring a webhook through API or configuration files,
it is no longer necessary to configure the request_timeout of the resource. Only configuring the http request_timeout is sufficient, and the request_timeout in the resource will automatically be consistent with the http request_timeout.