{{ model.name }} via RPC resolves to 'request' instead of the model name

[saraleon1]

Describe the bug

The model object appears to store 'request' instead of the model name when generating SQL in the IDE

Steps To Reproduce

1. In dbt Cloud, create a new model with the following jinja:

-- {{ model }}
--
-- {{ model.name }}
--
-- {{ this }}

2. Click 'compile sql' and observe the model name resolve to 'request' instead of your model name
3. Run the model in the IDE, and observe the correct model name resolve

Expected behavior

Generated SQL resolves to the model name rather than 'request'

Screenshots and log output

Loom link: https://www.loom.com/share/568facc746f04064819aa8442f5abc97

System information

Which database are you using dbt with?

• postgres
• redshift
• [ x] bigquery
• snowflake
• other (specify: ____________)

The output of dbt --version:

0.20.2

The operating system you're using:
dbt Cloud
The output of python --version:
n/a

Additional context

Add any other context about the problem here.

[jtcohen6]

@saraleon1 Thanks for the detailed report! You're totally right. Unfortunately, this is a limitation of how interactive SQL commands (compile_sql, run_sql) are implemented in the RPC server today. While it's possible to compile/run with project context, it isn't possible to compile/run arbitrary SQL with the context of a specific node.

dbt does create a placeholder node for interactive RPC requests—and it's named request. (Ugh.) I think we could do a better job here, along the lines of the proposal(s) in https:/dbt-labs/dbt/issues/3587. Given that a significant rework of the dbt Server is in our near-term future, which will include a top-to-bottom rethink of how we support interactive SQL requests, I think we ought to tackle this issue in the context of that broader effort.

In the meantime, so long as dbt doesn't think it's compiling/running a particular model, rather than compiling/running a chunk of SQL named request, dbt-Jinja expressions such as model, this, and is_incremental() won't return correct results.

I'm going to close this as a dupe of #3587.