Handle gRPC error explicitly

[iaroslav-ciupin]

TL;DR

gRPC errors should NOT be wrapped into codes.Internal, but converted to FlyteAdminError with same status code and message.

Type

• Bug Fix
• Feature
• Plugin

Are all requirements met?

• Code completed
• Smoke tested
• Unit tests added
• Code documentation added
• Any pending items have an associated Issue

[codecov]

Codecov Report

Merging #602 (2c363ec) into master (86c00cc) will increase coverage by 1.62%.
Report is 1 commits behind head on master.
The diff coverage is 81.81%.

❗ Current head 2c363ec differs from pull request most recent head 53764a6. Consider uploading reports for the commit 53764a6 to get more accurate results

@@            Coverage Diff             @@
##           master     #602      +/-   ##
==========================================
+ Coverage   58.66%   60.29%   +1.62%     
==========================================
  Files         171      171              
  Lines       16464    13462    -3002     
==========================================
- Hits         9659     8117    -1542     
+ Misses       5954     4493    -1461     
- Partials      851      852       +1     

Flag	Coverage Δ
unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
plugins/registry.go	100.00% <ø> (ø)
auth/handlers.go	35.79% <62.50%> (+0.68%)	⬆️
pkg/rpc/adminservice/util/transformers.go	100.00% <100.00%> (ø)

... and 154 files with indirect coverage changes

[katrogan]

Just curious, when have you observed flyteadmin passing along raw gRPC errors?

[iaroslav-ciupin]

@katrogan when I execute pyflyte run ... and get a validation error back(like no node can satisfy task resource...), I actual get back

code = codes.Internal
message = code:codes.InvalidArgument message: no node can satisfy task resource...

and same error gets flytepropeller(saw that in logs). Basically InvalidArgument was wrapped into Internal