Strange Error occurance in Erlang rfc4627

Question

    {ok,RequestData,_} = rfc4627:decode(Arg#arg.clidata)

When it match the Output of

    rfc4627:decode(Arg#arg.clidata)

to

    {ok,RequestData,_}

it gives a {badmatch, ....} error

But I Copied the output in the error msg and matched to

    {ok,RequestData,_}

in a erlang shell, Then it matches without any error.

This error only happens randomly. I can't figure out a reason. Sometimes it match and code works without any error. And sometimes it gives a error and yaws code crashes.

This is the error msg

    <h2>Internal error, yaws code crashed</h2><br /><hr />
    <pre>

    ERROR erlang code threw an uncaught exception:
    File: /usr/local/var/yaws/www/prime/yaws/session.yaws:1
    Class: error

    Exception: {badmatch,{ok,{obj,[{"action",<<"GET_SESSION_INFO">>}]},[]}}
    Req: {http_request,'POST',{abs_path,"/prime/yaws/session.yaws"},{1,1}}
    Stack: [{session,handle,2,
             [{file,"/root/.yaws/yaws/default/session.erl"},{line,30}]},
    {yaws_server,deliver_dyn_part,8,
                 [{file,"yaws_server.erl"},{line,2801}]},
    {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1215}]},
    {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1052}]},
    {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
    </pre><hr />

Answer 1

Finally I've found the issue. I have 2 different interfaces in same server and both of them uses the same file with the same file name. but code inside is bit different. that's the problem. when I go to one interface it dynamically compiles the yaws and create an erl file in a temporary path. Then if I try to go to the other interface it does not compile the yaws again instead it refers the same erl file from the other interface because both files have the same name. The error occurs when it tries to match the request data comes from the interface. because that 2 interfaces send request data in 2 different formats.

Answer 2

From the error message it is clear that value returned from rfc4627:decode/1 should easily match with three-tuple. So that's not the problem

Your issue might be with pattern matching with some "other" variable in function call. Especially if you have RequestData defined earlier, than with your code you would just compare previous value with this returned from rfc4627:decode/1.

It is also worth mentioning that while _ will pattern-match to anything (or will not pattern match if you will), the variables starting with underscore (like _Reminder) will pattern match (they just won't give you warnings if they are unused).

Edit

If you look at = operator in Erlang it could mean two different things. Either it could be assignment or pattern match, or both in your case (what you are trying to do is pattern match on ok atom, and at the same time assign new value to RequestData). So, depending on ReqestData being bound or not (already having some value, or not) you will have different behavior.

I'm assuming that ReqestData already is bound when you call {ok,RequestData,_} = rfc4627:decode(Arg#arg.clidata). In that case, we just pattern match (compare) value returned by decode and assigned to ReqestData, which can either pass or fail. For example it could be bound to null or false, which are the values that could be returned by decode. And since it all depends on data you are getting outside of your system, it could explain sometime passing/sometime failing behaviour.