# 🕵️ Compilou, mas o RPO não mudou? O mistério das compilações que vão para o limbo no Protheus
Quem desenvolve em **AdvPL/TLPP no Protheus** provavelmente já passou por uma situação parecida:
> Compilei o fonte.
> O VS Code informou que compilou.
> Não apareceu erro.
> Executei novamente...
> **e o comportamento continuou exatamente igual.**
A primeira reação normalmente é desconfiar de tudo.
* Será que compilei o fonte correto?
* Será que estou conectado no ambiente certo?
* Será que existe outro fonte com a mesma função?
* Será que o VS Code não enviou a compilação?
* Será que o AppServer está usando algum cache?
> Ou, no clássico método científico do desenvolvedor:
>> **"Vou colocar um `ConOut()` aqui só para ter certeza."** 😂
Pois bem.
Depois de algumas ocorrências desse comportamento, finalmente encontrei uma situação que explica pelo menos parte desses misteriosos casos de:
## 👻 "Compilou, mas não atualizou o RPO"
O cenário é relativamente simples.
Você está desenvolvendo normalmente pelo **VS Code**, conectado a determinado ambiente/RPO.
A conexão permanece ativa.
Enquanto isso, **um pacote/patch é aplicado nesse mesmo ambiente**.
O detalhe importante é que sua sessão de desenvolvimento continua trabalhando com a referência do **RPO que estava carregado anteriormente em memória**.
O RPO em disco foi alterado pela aplicação do pacote.
Mas sua conexão continua vinculada ao estado anterior.
E aí nasce uma situação particularmente traiçoeira:
```text
VS Code
│
│ conexão já estabelecida
▼
AppServer
│
├── RPO carregado/referenciado em memória
│
│ ⚠ estado anterior
│
▼
Compilação aparentemente OK
Enquanto isso...
Aplicação do pacote
│
▼
RPO em disco
│
└── estado novo
```
> Você continua compilando.
* O VS Code pode informar sucesso.
* Você altera o fonte novamente.
* Compila novamente.
* Executa.
> Nada.
* Compila de novo.
> Nada.
E começa aquela agradável fase do desenvolvimento conhecida como:
> **"Estou ficando maluco ou esse fonte não está compilando?"** 🤡
## 🗑️ Suas compilações estão indo para o "limbo"
Na prática, o problema não necessariamente está no seu fonte.
O problema está no **estado da conexão e do RPO mantido pelo AppServer** depois que o repositório foi alterado externamente pela aplicação do pacote.
A sessão que estava aberta antes da atualização não necessariamente passa a trabalhar automaticamente sobre o novo estado do RPO.
Resultado:
**você acredita estar compilando sobre o RPO atualizado, mas sua conexão ainda está presa ao contexto anterior.**
E isso explica por que o problema parece tão aleatório.
Na verdade, não é exatamente:
> "Às vezes o Protheus não atualiza minha compilação."
Existe uma condição que pode provocar o comportamento:
> **A conexão de desenvolvimento já estava ativa quando ocorreu uma alteração externa no RPO, como a aplicação de um pacote.**
Esse detalhe muda completamente a investigação.
---
# 🔌 A solução: reconectar
Se um pacote foi aplicado no ambiente enquanto sua conexão de desenvolvimento estava ativa, a primeira providência deveria ser:
1. **Desconectar o VS Code do ambiente;**
2. **Conectar novamente;**
3. **Recompilar o fonte.**
Mas, quando possível, prefiro uma abordagem ainda mais segura:
> **reiniciar o serviço/AppServer utilizado para desenvolvimento e depois reconectar o VS Code.**
Assim eliminamos qualquer dúvida sobre o estado do RPO mantido pelo processo.
O fluxo passa a ser:
```text
Aplicação do pacote
│
▼
Novo RPO
│
▼
Reinicia AppServer
│
▼
Reconecta VS Code
│
▼
Compila novamente
│
▼
Novo RPO
```
---
# ⚠️ O detalhe perigoso: a compilação pode parecer bem-sucedida
Esse é, para mim, o ponto mais importante.
Se houvesse simplesmente um grande:
```text
ERROR: RPO CHANGED - RECONNECT YOUR ENVIRONMENT
```
ninguém perderia muito tempo. 😅
O problema é justamente a possibilidade de a operação **aparentar ter ocorrido normalmente**.
Do ponto de vista do desenvolvedor:
```text
Fonte alterado
↓
Ctrl + F9
↓
Compilação OK
↓
Executa rotina
↓
🤨
```
E então começamos a investigar o código quando, na realidade, deveríamos estar investigando **o estado do ambiente**.
---
# 🧠 Uma nova regra para minha checklist de desenvolvimento Protheus
Depois dessa descoberta, acrescentei mentalmente mais uma pergunta à investigação quando uma alteração "não entra":
```text
☑ Estou no ambiente correto?
☑ Estou compilando o fonte correto?
☑ Existe outro fonte/função sobrescrevendo este?
☑ O fonte realmente foi compilado?
☑ O AppServer correto está sendo utilizado?
☑ ALGUM PACOTE FOI APLICADO DEPOIS QUE ME CONECTEI?
```
Se a resposta para a última pergunta for **sim**:
> 🔌 **desconecta e conecta novamente.**
E, preferencialmente:
> 🔄 **reinicia o AppServer de desenvolvimento.**
Só depois disso vale a pena começar a colocar `ConOut()`, breakpoint em tudo quanto é canto e questionar as próprias escolhas profissionais. 😂
---
# 💡 A lição vai além do Protheus
Esse caso também lembra uma coisa importante sobre desenvolvimento em ambientes com **estado mantido em memória**.
O arquivo que existe **no disco** e aquilo que determinado processo possui **carregado em memória** não são necessariamente a mesma coisa naquele instante.
Quando outro processo modifica um artefato compartilhado — neste caso, o **RPO** — conexões previamente estabelecidas podem continuar trabalhando sobre um estado que deixou de representar aquilo que agora existe fisicamente no ambiente.
Por isso, quando houver:
**VS Code conectado + aplicação de pacote + comportamento estranho nas compilações**
antes de perder uma hora procurando um bug inexistente no fonte...
## 🔌 Reconecte.
E, se puder:
## 🔄 Reinicie o AppServer.
Às vezes o código está certo.
A compilação também.
Você só estava compilando para...
# 🕳️ o RPO do multiverso. 😎
---
**Desenvolvimento Protheus também é entender o que acontece entre o `Ctrl+F9` e o RPO.**
E são justamente esses pequenos detalhes de ambiente que conseguem consumir horas de debugging quando não sabemos que eles existem.
---
#DNATech,#AdvPL #TLPP #Protheus #TOTVS #VSCode #AppServer #RPO #Desenvolvimento #Debug #Programacao #SoftwareEngineering #TOTVSProtheus
Comentários
Postar um comentário